이전 강의에서 말한 TLS 정보들이 K8s에서 어떻게 사용되는지 알아보자.
크게 두 가지로 나뉜다.
1. Server Certificates for Servers
2. Client Certificates for Clients
1. Server Certificates for Servers
K8s 내 다른 컴포넌트끼리 통신하는 방법.
Api server는 https service를 expose하니까, 클라이언트들과 모든 통신을 암호화하기위해 인증서를 필요로한다.
그래서, Kube-API서버를 위한 apiserver.crt, apiserver.key를 만든다.
etcd, kubelet도 마찬가지다. 각자 정보를 저장하고, worker노드를 관리하기에 certificate와 key가 각각 필요하다.
2. Client Certificates for Clients
Clients는 service/k8s 에 access하는 사람/것(ex. administrator, kube-scheduler)
- 사용자는 서버를 인증하기 위해 인증서와 keeper를 필요로 한다.
- scheduler는 kube-api server입장에서는 client로서, cleint certificate를 이용하여 그것의 id를 validate 해야한다.
그래서 인증서와 key가 필요하다.
- kube controller mgr, kube-proxy도 동일하다.
- 그리고, kube-api 서버도 etcd 및 kubelet server와 통신할 땐 client가 된다. 그래서 새로운 인증서/키를 생성하거나
혹은 기존 것을 동일하게 사용한다.
점점 복잡해지니 그룹핑을 해보자.
결국 api, kubelet service는 client certificate도 가지고 있고, server certificate도 가지고 있다.
그럼 인증서는 어떻게 만들어질까?
이전 강의에서 본 것처럼, 인증서를 등록하기 위해서는 certificate authority(CA) 가 필요하다.
그리고, CA는 전체 인증서와 키의 짝을 들고 있으므로, ca.crt / ca.key를 생성하여 클러스터내 사용되는 모든 인증서를 합친다.
인증서를 생성하기 위해서는, 위와 같은 3개의 툴이 있다.
그리고 이 강의에서는 openssl을 다뤄본다.
key certificates를 만들기 위한 방법은 아래와 같다.
1) Generate Keys: private key를 생성한다
#openssl genrsa -ou tca.key 2048
2) Certificate Signing Request
# openssl req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr
디테일한 인증서 정보들이 포함되어 있고, component의 이름을 specify한다. (ex. CN)
예를 들어, CA를 위한 인증서를 만드니까, 그 것의 이름은 KUBERNETES-CA가 된다.
3) Sign Certificates
# openssl x509 -req -in ca.csr -signkey ca.key -out
인증서를 등록한다. 이제 CA는 그것의 Private와 root certificate를 가지고 있다.
이제 client certificate를 만들어보자.
admin 유저를 위한 인증서부터 시작하는데, 위 server 절차와 동일한 절차를 따른다.
1) Generate Keys: private key를 생성한다
2) Certificate Signing Request
# openssl req -new -key admin.key -subj "/CN=kube-admin/OU=system:masters" -out ca.csr
3) Sign Certificates
# openssl x509 -req -in ca.csr -signkey ca.key -out
# openssl x509 -req -in admin.csr -CA ca.crt -CAKey ca.k
// ca.crt가 추가된다: ca key pair와 인증서를 등록하기 때문. 이건 클러스터 내 유효한 인증서를 만든다.
key와 인증서를 생성하는 전체 절차는 usr account를 생성하는 절차와 비슷하다.
인증서는 validated user ID이고, key는 password 같기 때문인데, TLS는 훨씬 안전하다.
그런데, 다른 user들과 해당 user를 어떻게 구분할까?
user 계정은 다른 basic user가 아니라, admin user의 id를 필요로 한다.
그렇다면, 이건 그룹 생성을 통해 해결해줄 수 있는데, 이 또한 인증서에 언급이 되어야 하므로
O=system:masters 옵션을 통해 CSR을 보내준다.
그럼, 이 인증서들과 무엇을 할까?
admin 인증서로는 cluster를 관리한다. curl 명령어로 username/password 대신 인증서를 사용할 수 있다.
다른 방법은, kube-config에 작성해놓는 것이다. 대부분의 client들이 이 방식을 사용한다.
+ cleint들은 server로부터 전달된 인증서를 validate하기 위해 CA public certificate copy가 필요하다.
(web app의 경우 user brower내에 자동으로 설치되어 있는)
k8s는 다양한 컴포넌트들이 있으므로, 서로를 검증하기 위해 root certificate 복사본을 각각 가지고 있다.
server side certificate의 예로 etcd 서버를 봐보자. 동일한 절차를 따르는데,
1) 다른 멤버들(Peers)과 통신하기 위해 추가적인 peer's certificates가 필요하다.
2) 인증서가 만들어지면, etcd 서버가 시작될 때 그것들을 정의한다.
- key, cert file option 및 여러 옵션이 있고,
클라이언트가 connect하는 서버가 유효한지 체크하기 위한 root certification이 있다.
kube-api server를 보자.
kube-api server의 경우, 매우 많은 연동포인트들과 요청을 받기 때문에 kube-api server외에도 k8s 등 다양한 이름을 가지고 있다. (외부에서 봤을 땐, kube-api server를 모르므로 k8s라는 이름을 갖고있는 것이다)
그리고 이런 이름들은 발급된 인증서에 반드시 명시가 되어 있어야 하는데, 그걸 openssl.cnf 파일의 [alt_name]에 명시한다.
그리고, api server가 클라이언트로서 etcd, kubelet과 통신할 때
이런 인증서들은 api server의 service configuration 파일 내에 정의되어야 한다.
1) --client-ca-file: its client를 증명하기 위해 필요 (모든 컴포넌트들이 필요함)
2) --tls-cert/private key: api server 인증서
3) --etcd / --kubelet 정의
kubelet server를 보자.
여긴 이름을 어떻게 정의할까? kubelet이 아니라 각 node별로 정의한다.
kubelet의 client 또한 api server와 통신하기 위해 정의를 해야하는데,
api server는 어떤 노드가 인증되어 있는지, 적합한 퍼미션을 주는지 알아야 하기 때문에
이름 포맷이 제대로 정의되어야 한다.
node는 이전 apiserver, etcd들 처럼 시스템 컴포넌트이기 때문에 format은 system부터 시작한다.
그럼 api 서버는 어떻게 맞는 퍼미션을 줄까? 그룹네임을 이용한다.
node 또한 system node라는 그룹 네임을 추가한다. 이건 뒤에서 더 알아본다.
출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의