[K8S - CKA] TLS in K8S

1. TLS in K8S

---

 

쿠버네티스는 마스터 노드와 워커 노드로 되어있고 이는 서로 소통합니다. 이때 서로 소통을 하기 위해서 보안이 중요합니다. [Server Certificates for Servers] / [Client Certificates for Clients] 소통을 하는데 이렇게 소통을 하기 위해서는 보안이 중요하다는 말 입니다. 예를 들어서 apiserver와 scheduler끼리 통신을 한다던지요. (Server Certificates for Servers의 경우)

 

 

1 - 1) Server Certificates for Servers

---

Kube API Server에는 apiserver.crt (public key) / apiserver.key (private key)가 존재 

 

ETCD Server에는 etcdserver.crt (public key) / etcdserver.key (private key)가 존재

 

KUBELET Server에는 kubelet.crt (public key) / kubelet.key (private key)가 존재

 

1 - 2) Clients Certificates for Clients

---

admin이 이때 Kube API Server에 접근 하는 상황을 가정해봅시다.

 

1) kubectl REST API 요청으로 APISERVER에 사용자의 요청을 보내면 admin.crt , admin.key으로 tls 요청을 통해서 보안 요청을 할 것 입니다.

 

2) 이제 적절한 워커 노드에 붙이려면 Scheduler로 어떤 워커 노드에 붙일지 로직을 짜야합니다. 마찬가지로 보안 통신을 이용해서 통신을 하는데요 scheduler.crt, scheduler.key를 통해서 같은 tls 처리를 합니다.

 

3) 이후에는, 워커 노드에 붙이기 위해서 Kube Controller Manager를 통해서 tls 처리를 합니다.

 

4) Kube-proxy tls 설정을 하기 위해서 연결..

 

5) 이후 ETCD와 연결하기 위해서 연결

 

6) 이후 Kubelet과 연결하기 위해서 연결

 

너무 많습니다. 이를 큰 범위로 나누어서 봅시다.

연결 범위

 

 

종류별로 나눈 형태

 

 

2. Generating TLS in K8S with OpenSSL 

---

우선 생성하는 방식은 여러 가지 입니다. OpenSSL, CFSSL, etc...

 

이중 OpenSSL을 사용하여 생성 해봅시다.

 

2-1) Server Certification

---

 

1. ca.key를 만들어 봅시다.

openssl genrsa -out ca.key 2048

 

 

 

2. ca.csr을 만들어 봅시다. 이는 K8S 클러스터에서 인증을 받기 위해서 CA로 보내는 요청입니다. 

 

openssl req -new -key ca.key -subj "/CN=KUBERNETS-CA" -out ca.csr

 

명령 설명

• openssl: OpenSSL 명령을 실행하는 명령어입니다.
•  req: CSR 및 관련 작업을 수행하는 OpenSSL 하위 명령입니다.
• -new: 새로운 CSR을 생성하라는 옵션입니다.
• -key ca.key: CSR과 함께 사용할 개인 키 파일의 경로를 지정합니다. 여기서는 ca.key 파일이 사용됩니다.
• -subj "/CN=KUBERNETS-CA": 서브젝트 필드를 지정하는 옵션으로, 인증서의 주체를 정의합니다. /CN=KUBERNETS-CA는 Common Name (CN)이 "KUBERNETS-CA"로 설정되도록 지정합니다.
• -out ca.csr: 생성된 CSR을 저장할 파일의 경로와 이름을 지정합니다. 여기서는 ca.csr 파일이 생성됩니다

3. Certificate 사인 (ca.crt 만듦)

 

openssl x509 -req in ca.csr -signkey ca.key -out ca.crt

 

우리가 sign을 위해서 csr 만든 파일을 사인 요청을 하는 겁니다.

 

그러면 CA는 private key와 route certificate file을 가집니다. (자체 서명)

 

2-2) Client Certification

---

1. 키 생성

openssl genrsa -out admin.key 2048

(admin.key) 

 

2. CSR 생성 (Certificate Signing Request)

openssl req -new -key admin.key -subj \ "/CN=kube-admin/O=system:master" -out admin.csr

 

/O=system:masters : 을 추가하면 일반 유저가 아닌 클러스터의 admin 유저임을 인지한다.

 

3. crt 생성 
openssl x509 -req -in admin.csr –CA ca.crt -CAkey ca.key -out admin.crt

 

위에서 생성한 Server Certification 중 ca.crt를 이용해서 admin.crt가 인증된 쿠버네티스트 클러스터 사용자임을 인증한다. 이제 certificate (crt)는 userID 같은 것이고 admin.key가 password 같은 것입니다.

 

그러면 <그림1>과 같은 형태로 Cert가 발급된다. GROUP SYSTEM : MASTER로 KUBE-ADMIN으로 이를 주의 깊게 봐야하는데 아까 /CN=kube-admin/O=system:master CSR 생성중에 저런 명령어를 봤을 것이다. 그럼 하부의 이름과 그룹을 보면 아래의 명령어로 셋팅 되는 것을 볼 수 있다.

 

그렇다면, 유저 정보 말고도 Scheduler, ControllerManager, Kube-Proxy 등도 이렇게 되어있다는 것을 유추 할 수 있다.

 

예를 들어서 openssl req -new -key admin.key -subj \ "/CN=kube-Scheduler/O=system:master" -out admin.csr 이렇게 설정하면 <그림2>와 같이 말이다.

<그림1>

<그림 2>

 

 

자, 그래서 이 Cert로 무엇을 할 껀가요?

 

kube-apiserver로 userID, password로 넣어서 각각의 요청을 보내지 않고 아래와 같이 curl 요청마다 이렇게 crt, ca, key를 보내서 인증 할 수 있고 이를 간단히 하려면 ConfigMap으로 만들어 두고 사용합니다.

 

curl https://kube-apiserver:6443/api/v1/pods \
--key admin.key --cert admin.crt 
--cacert ca.crt

 

apiVersion: v1
clusters:
  - cluster:
		certificate-authority: ca.crt
		server: https://kube-apiserver:6443
	name: kubernetes
kind: Config
users:
  - name: kubernetes-admin
	user:
		client-certificate: admin.crt
		client-key: admin.key

 

모두 봤으면 알겠지만 각자의 개인 키와 각자의 공개 키들을 가지지만 모두 CA의 공개키를 가지고 있어야 (무조건 루트 certification file을 이용해서) 요청을 처리 할 수 있는 것을 볼 수 있습니다.

 

2-3) Server Certification (GROUP SYSTEM:NODES)

---

ETCD Server의 생성 방법

 

생성과정은 위와 동일하지만 고가용성 환경에서는 다른데요 ETCD는 클러스터 내부에 두가지 이상의 ETCD를 가질 수 있으며 이때, 각각의 ETCD에 대해서 모두 ca 처리를 해주어야 합니다. 이를 추가 하기 위해서는 etcd.yaml에 ca와 route file crt가 필요합니다.

 

Kube- API SERVER도 어떻게 생성이 될까요?

 

모든 작업은 API SERVER가 처리를 하는데 어떻게 될까요? (여담으로 kube-apiserver가 k8s다.)

Kube API SERVER 사용을 위해서는 모든 설정을 동일하게 하지만 위의 CSR 생성 부분에서 생성되는 Certification Signing Request 시에 openssl.cnf 파일을 열고 아래와 같이 설정을 해두어야 합니다.

 

openssl.cnf

[req]
req_extensions = v3_req
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, 
subjectAltName = @alt_names
[alt_names]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster.local
IP.1 = 10.96.0.1
IP.2 = 172.17.0.87

 

그리고, 이것이 작동하기 위해서는 KUBE APISERVER.yaml 설정 파일에 --client-ca-file(ca.pem) 설정을 해주어야 합니다. 그러고 나서, --tls-cert-file(.crt)  및 --tls-private-key-file(.key) 설정을 해주어야 합니다.

 

위와 같이 설정을 ETCD와의 연결을 위해서 동일한 셋팅을 하고 kubelet에 대해서도 같은 셋팅을 합니다.

 

KUBECTL NODES 

 

각각의 Node 별로 KUBELET에 접근 하기 위해서 clientCAFile 및 tlsCertFile 및 tlsPrivateKeyFile 셋팅을 꼭 해주어야 합니다.

 

kubelet-config.yaml (node01)

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
  x509:
    clientCAFile: "/var/lib/kubernetes/ca.pem"
authorization:
  mode: Webhook
clusterDomain: "cluster.local"
clusterDNS:
- "10.32.0.10"
podCIDR: "${POD_CIDR}"
resolvConf: "/run/systemd/resolve/resolv.conf"
runtimeRequestTimeout: "15m"
tlsCertFile: "/var/lib/kubelet/node01.crt"
tlsPrivateKeyFile: "/var/lib/kubelet/node01.key"

 

3) KUBEADM의 위대함

---

위와 같은 설정들은 실제 사용중인 운영중인 서버에 대부분 쓰이지 않으며 네이티브 환경에서의 쿠버네티스 상황에서 필요한 설정들이다. KUBEADM은 이를 POD로 자동화해서 프로비저닝 해버리죠.

 

/etc/kuberenetes/manifests/kube-apiserver.yaml으로 들어가서 ca, crt, pem 파일을 확인 할 수 있습니다.

 

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout 이 명령어로 안의 모습을 볼 수 있습니다. 이때 확인 할 것은 CN NAME이 올바른지 x509v3 AlterName이 올바른지 등을 체크 할 수 있습니다.

 

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 3147495682089747350 (0x2bae26a58f090396)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        Validity
            Not Before: Feb 11 05:39:19 2019 GMT
            Not After : Feb 11 05:39:20 2020 GMT
        Subject: CN=kube-apiserver
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d9:69:38:80:68:3b:b7:2e:9e:25:00:e8:fd:01:
                    ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Alternative Name:
                DNS:master, DNS:kubernetes, DNS:kubernetes.default,
                DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local,
                IP Address:10.96.0.1, IP Address:172.17.0.27