K8S TLS Certificate 정리

이번 포스팅은 K8S 클러스터의 TLS Certificate에 대해 정리한다.  

 

K8S TLS에 대해 알아보기 전, TLS Certificate에 대한 기본적인 내용을 짚고 넘어가자. 

 

Certificate는 다음과 같이 세 종류가 있고, 기본적으로 세가지 모두가 필요하다.

 

- CA에서 발급한 root certificate

- 서버에서 발급한 server certificate

- 클라이언트에서 발급한 client certificate 

 

 

만약 Certificate에 대해 잘 모르겠다면 다음을 참고. 

TLS Certificate란?(대칭 키, 비대칭 키, CA, PKI)

 

 

 

 다음은 certificate와 private key를 구분하는 방법.  

 

 

certificate는 뒤에 crt 또는 pem 확장자가 붙어 있으며

private key의 경우에는 key가 확장자로 붙거나 파일명에 key가  들어간다.  

 

 

 

이제 쿠버네티스로 넘어와 TLS에 대해 생각해보자.

 

클러스터는 마스터노드와 워커노드로 이루어져있고,

각 서버간에는 외부에서 알 수 없게 암호화된 데이터를 주고 받아야 한다.  

 

또한 k8s 어드민이 kube-api서버와 통신하기 위해서는 kube-api 서버는 통신하고 있는 클라이언트가

K8s 어드민이라는 것을 알아야 한다. 

 

이외에도 클러스터 내부에 여러가지 클라이언트-서버 관계가 있다.  

 

결국 정리해보자면 서버를 위한 server certificate와 client를 위한 client certificate가 필요한 것이다.  

 

 

 

 

< server certificate와  client certificate >

 

 

admin, scheduler, kube-controller-manager, kube-proxy, kubelet는 kube-api server의 client가 된다. 

 

kube-api server는 etcd server의 client가 된다. 

 

kube-api server는 Kubelet의 client가 된다.  

 

이제 이 관계에 맞게 certificate를 생성하고 configure해주어야 한다.  

 

EasyRSA, OpenSSL, CFSSL 등과 같이 certificate를 생성하는 다양한 툴들이 있지만

여기서는 OpenSSL을 이용하겠다. 

 

 

 

1. Root certificate 생성하기  

 

server certificate와 client certificate를 생성하기 앞서 CA로부터 root certificate를 생성해줘야 한다. 

 

 

1) private key 생성하기

 

2) CSR 요청: CA로 certificate signing request 보내기  

 

3) certificate에 사인하기 

 

(ca.crt와 ca.key에 접근한 가능한 누구든지 K8S 클러스터에 대한 cerficate를 발급받을 수 있다.

즉, ca.crt와 ca.key는 안전하게 보관되어야 한다.)

 

 

< client side certificate와 server side certificate 생성하기 >

 

어드민, 스케줄러, 컨트롤러 매니저, kube-api server등 certificate 생성 과정은 모두 동일하므로 

쿠버네티스 클러스터에 접근할때 사용되는 admin certificate만 생성해본다.  

 

1) private key 생성하기

 

2) CSR 요청: CA로 certificate signing request 보내기  

 

3) CA에서 발급받은 ca.cat와 ca.key로 admin의 certificate를 만들기 

 

다음과 같이 admin의 key와 crt를 지정해줌으로써 Kube-api server 에 접근할 수 있다. 

 

이외에도 이러한 파일들에 대한 정보를 담은 kube-config.yaml을 이용해서 kube-api server에 접근할 수도 있다. 

 

 

 

※ ETCD의 CA

ETCD는 Kube-api server와 다른 CA를 이용하므로 root certificate를 따로 발급 받아줘야 한다. 

 

 

 

 

< server side certificate detail >

 

cerficate를 생성 후, server side에서는 client에 맞는 certificate 설정을 추가적으로 해주어야 한다. 

 

 

1. ETCD

 

etcd는 고가용성을 위해 multiple etcd 형태로 만들 수 있다.

 

이 때 추가적으로 만들어진 ETCD를 peer라고 하는데  

ETCD 서버는 peer를 위해 Etcdpeer1.crt와 etcdpeer1.key를 추가적으로 생성한다. 

 

 

 

 

 

 

 

2. kube-apiserver

 

 kube- apiserver는 certificate를 생성할 때 DNS를 따로 정의한 openssl.cnf파일을 이용하는데 

다음 과정을 통해서 자세히 알아보자. 

 

1) 프라이빗 키 생성과정은 똑같다. 

 

2) csr을 생성할 때 openssl.cnf를 추가한다.(기존의 csr생성과의 차이점)

 

 

openssl.cnf을 추가하는 이유는 kube-apiserver를 부르는 이름이 다양하기 때문이다.

kube-apiserver를 kubernetes, kubernetes.default, kubernetes.default.svc라고도 한다.  

 

 

3) certificate 생성 

 

/etc/kubernetes/manifest/kube-apiserver.yaml 에는 kube-apiserver에 사용된 key파일, crt파일들이 명시되어 있다. 

 

 

 

 

3. kubelet 서버 

 

각 노드에서  돌아가는 api 서버로 각 노드에는 한 쌍의 certificate와 key가 필요하다.  

 

certificate 이름을 명시할 때 kubelet이라 안하고 노드의 이름을 이용해서 certificate를 지정한다.  

 

각 노드마다 certificate 생성 후, kubelet-config.yaml에 정의한다. 

 

 

 

 

 

< Certificate detail 확인하기 (kubeadm으로 클러스터를 생성한 경우) >

 

kube-apiserver의 certificate를 확인해보자. 

 

 

/etc/kubernetes/pki/apiserver.crt 경로에 kube-apiserver가 발급받은 certificate가 존재한다.

 

 

 

다음 커맨드를 통해 certificate를 확인할 수 있다.  

 

 

Issuer: 누가 발행했는지

Validity: certificate 만료 기간.  

Subject: certificate의 객체

Alternative name: 사용가능한 DNS