CKS 준비 -

CKS 준비

1. 개요 : Security Principles

  • defense in depth : 여러겹 방어
    • DRY?(Don't repeat yourself?).보안에서는 중복이 좋다.
  • least privilege : 최소권한
  • limiting the attack surface :

kubernetes security categories(or layer)

  • Application
  • Kubernetes
  • Hosts
  • Network

ETCD를 지켜요

APIServer 액세스를 조심해요

2. 전체 구조

쿠버네티스는 유저 인증 정보가 포함되어 있지 않으며, 인증에는 pki 구조를 이용한다. 일반적인 웹에서 사용하는 TLS와 다른 점은 서버의 인증 뿐만 아니라 클라이언트의 인증도 함께 진행한다는 점이다.

curl --cacert rootCA.pem https://localhost:8443/
# 일반적인 자체 서명 ca를 이용한 TLS 요청. ca의 인증서(rootCA.pem) 정보를 이용하여 서버(localhost)의 인증서가 정상적인 인증서임을 확인한다.
# 일반적이지는 않지만 인증된 클라이언트의 요청만 받는 경우는 다음과 같이 요청할 수 있다. 클라이언트 인증서(client.pem)와 키(client-key.pem)를 이용하여 디지털 서명(해싱)하여 전송한다.
# 서버는
# ca인증서(rootCA.pem)를 통해 해당 인증서가 정상 동작인이 확인
# ??? 클라이언트 인증서가 인증서의 소유권 증명
#
curl --cacert rootCA.pem --cert client.pem --key client-key.pem https://localhost:8443/
# client(kubectl)에서 apiserver로 요청시 개별 클라이언트 인증서를 포함하여 전송할 수 있다.
kubectl get pod -n kube-system --client-certificate=client.pem --client-key=client-key.pem
# 혹은 kubeconfig 옵션을 이용하여 클라이언트 인증서 정보가 포함된 설정 파일을 같이 던질 수 있다.
kubectl get pod -n kube-system --kubeconfig=$HOME/kubeconfig

PKI와 CA

  • Public Key Infrastructure
  • Certificate Authority : 인증기관. ca.crt = 생성한 root ca.
  • Certificate : Public Key
  • Public Private Key : 개인키. 개인키로 암호화->디지털 서명(Digital signature)

인증서가 아주 많이 있다.

각 인증서의 위치

필요한 인증서(public key)를 클러스터 조인 시점에 모두 각 호스트에서 가지고 있다.

  1. ca
  • 위치 : master노드의 /etc/kubernetes/pki/ca.crt
  • 용도 : 인증서에 대한 인증 기관 인증서.
  1. apiserver 인증서
  • 위치 : master노드의 /etc/kubernetes/pki/apiserver.crt
  • 용도 : apiserver 서버 인증서
  1. client kubelet 인증서(apiserver -> worker kubelet)
  • 위치 : master노드의 /etc/kubernetes/pki/apiserver-kubelet-client.crt
  • 용도 : apiserver에서 worker의 kubelet을 호출할 때 사용하는 client 인증서.
  1. etcd 서버 인증서
  • 위치 : master노드의 /etc/kubernetes/pki/etcd/server.crt
  • 용도 : etcd 서버 인증서
  1. etcd 인증서(apiserver -> etcd)
  • 위치 : master노드의 /etc/kubernetes/pki/apiserver-etcd-client.crt.
  • 용도 : apiserver가 etcd에 접근할 때 사용. etcd 접근시 apiserver에 대한 클라이언트 인증서.
  1. scheduler -> api 인증서 마스터 노드의 /etc/kubernetes/scheduler.conf 내부에 client-certificate-data에 인증서가 포함

  2. contoller-manager -> api 인증서

  • 위치 : 마스터노드의 /etc/kubernetes/controller-manager.conf 내부에 client-certificate-data에 인증서가 포함
  • 용도 : 컨트롤러 매니저의 클라이언트 인증서. api 서버 호출시 사용.
  1. kubelet -> api 인증서
  • 위치 : 위치 정보가 /etc/kubernetes/kubelet.conf에 선언되어 있다.
client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem
  • 용도 : kubelet에서 apiserver 호출시 사용하는 클라이언트 인증서
  1. kubelet server 인증서
  • 위치 : kubelet 클라이언트와 거의 비슷하게 있다. /var/lib/kubelet/pki/kubelet.crt
  • 용도 : kubelet(서버) 인증서

참고

[1] https://www.youtube.com/watch?v=wqsUfvRyYpw

[2] https://coffeewhale.com/kubernetes/authentication/x509/2020/05/02/auth01/

network policies

  • pods are not isolated
  • 기본적으로 networkpolicy가 없으면 egress/ingress all allow임.
  • networkpolicy로 egress/ingress를 선언하면

예제 : networkpolicy로 default 네임스페이스의 아웃바운드(Egress) 트래픽 전체 차단

kind: NetworkPolicy
metadata:
name: exampleNetworkPolicy
namespace: default
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- {}

outbound udp/tcp 53 전체 차단

kind: NetworkPolicy
metadata:
name: exampleNetworkPolicy
namespace: default
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- ports:
- port: 53
protocol: TCP
- port: 53
protocol: UDP