Kubernetes Certificate 알아보기

- 목차

 

함께 보면 좋은 글.

https://westlife0615.tistory.com/411

CA (Certificate Authority) 알아보기

 

소개.

Kubernetes 의 인증 체계들 중에서 kubectl 과 Kubernetes Cluster 가 어떠한 인증 체계를 가지고 있는지 알아보려고 합니다.

기본적으로 CA 인증 체계를 따릅니다.

CA 인증 체계는 public key, private 로 구성되는 비대칭키를 사용하구요.

CA Chaning 방식으로 인증서가 보호됩니다.

이게 무슨뜻이냐면,

클라이언트와 서버는 서로 Public Key 와 Private Key 로 암복호화를 합니다.

클라이언트가 Public Key 로 암호화한 정보를 Private Key 를 가지는 서버만이 해독할 수 있고,

서버가 Private Key 로 암호화한 정보는 Public Key 를 가지는 클라이언트만이 해독할 수 있습니다.

이렇게 상호의존적인 방식으로 정보가 보호됩니다.

 

그리고 CA Chaining 은 인증서를 보호하는 방식입니다.

클라이언트와 서버가 사용할 Public Key 와 Private Key 는 하나의 인증서로써 관리가 되는데요.

이 인증서는 신뢰성이 강한 상위 기관에 의해서 1번 이상 암호화가 됩니다.

즉, 이러한 과정은 통해서 CA 인증 체계가 구성됩니다.

 

쿠버네티스에서 kubectl 로써 Kubernetes Cluster 와 소통하기 위해선 이러한 CA 인증 체계가 필요합니다.

그래서 쿠버네티스가 어떠한 방식으로 CA 인증을 처리하는지 알아보려고 합니다.

 

kubeconfig 구성.

아래 파일은 kubeconfig 에 해당하는 yaml 파일입니다.

apiVersion: v1
kind: Config
preferences: {}
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJek1USXhNVEF5TWpFek9Gb1hEVE16TVRJd09EQXlNakV6T0Zvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTUdoClVJWm9iMDY2M2hvc2I5QjZvaGRCVGthQXdvZjI0Uk5tVWZTQldqRGhSZzVtU2NQQXpwYnhiSEpJWmlhaFRIUG4KUlZ3TEpON210VU1uVXB1cHl4N2kwNXIwa3ovWmdNVVhXZlg1UzB6Z0tPWXdzcFc4KzdCMXNsWHhpRTE1RnZpWQpoN1R0ajY2dnVVa0YrdU02OHpsRkF1bzlrMHV5V05OZHprQzlrN3oxcGdvTytPOTVjYU13M2t2OTRuUld5bjlrCndGbXhwdGJBSThMZ250bEJJeEZBOU1VemhOUUZqbkVnR01ESzNxWGQ0R3VCV2hyV3RxeTVLemRwek14aEJiT2QKczMrdzRXc0w4ZlhteitLdkZzbzJ2OUJvaFFERHE2WmFHTm5uRS9RWGVxUDZHdHhSR3FpTTlRSWsvdVVmeHB5MgpqR2JzRnBJaDYxYzFub28vaGhrQ0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZFYjcrb0tDM1J3Sjk2RFl6YzB5NUNDcEcyVURNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBQy9rNnVycmVURlpkVXRIaytGdgpsTWRXTUpBMnNXeSs1SjB5M3plZDVpbTArUisvL2FhNUFzbHNtRldJS0xZMGppc29CaXB2ZWxlM1N2ZWM3R2JuCkVqUXYvdGcvS05QOG05STVpekR3YWxocjN0T1V6ZTU3TVJSZHBjbC9HS29BVHFDaTF5Y0JUT1VoK3NkY3paOGwKVHBoejcrMTMwVlNLb1lzOERwbUVvajZnMTZjYzJjUWI4TldaWWtYMjJVeWl0U3dLZzdlYnY4OVlSc3ZCeDlOdApBaWx1ZmJGYm9mK1FON0lBMW9tUld4NERJWG1OZHU4QWZTMXpUd2FleHArRVFaMHRISXQ0S0RMQUx0R3pZWHl2CmpNMGtOaUp4ckVrOHBzdHVFQk05RXpKQ1gvTHJYZzMwbVZlNWhvWHFWak5XTTBDNjVCT0t0azc2Q3JsZEhBeXcKaWc4PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    server: https://127.0.0.1:60662
  name: kind-test-cluster
contexts:
- context:
    cluster: kind-test-cluster
    user: kind-test-cluster
  name: kind-test-cluster
current-context: kind-test-cluster
users:
- name: kind-test-cluster
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURJVENDQWdtZ0F3SUJBZ0lJQlFYVVBJTS8wUG93RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TXpFeU1URXdNakl4TXpoYUZ3MHlOREV5TVRBd01qSXhOREJhTURReApGekFWQmdOVkJBb1REbk41YzNSbGJUcHRZWE4wWlhKek1Sa3dGd1lEVlFRREV4QnJkV0psY201bGRHVnpMV0ZrCmJXbHVNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQTNJd2hORHhnT2RKdE81ZjcKaVd3MmRyTURNcllDWjFOcXZvZkttK0tPVndrMmV4bHJOdFFCTlhVTDdWeW5rUGc1TlVlREdHM3ExdUx6dkhkdQpOcFFXc0hNQ1A3dE5kYUtvWXh2SittbkJqLzZycFoxSEtBdG5SYWx0VFhjc2tmSFZKMjZjR2EwcVVaQ1VXemcvCitFWThjQzUvQ2h1d2tTeG5ycDVRdFNoaGhVUHowN01rZC80S0ZvQ0dDNE9YS1VjQmpFTGhpTXlla215ZmViSFIKQlBVQ2wzaU42d0xtMHQ0dnZTMC83ZXVubmF6QmhrSEVYdWIvUEV6cnRIbGcrL0hkMVVrRTFVYWVYM3RGZzJlaQp0YzJnMkdnSS85cC8rdWx3VzdzRjVWcVErTGgzOXlXSDRPTThrZ05yQjdJdHRvNGVyaTg2OGVBMXo5UktLVTRNCmxrTkdNUUlEQVFBQm8xWXdWREFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUgKQXdJd0RBWURWUjBUQVFIL0JBSXdBREFmQmdOVkhTTUVHREFXZ0JSRysvcUNndDBjQ2ZlZzJNM05NdVFncVJ0bApBekFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBdlpiUzFPWitKSjVDaTB2VXhjdmxqeE1BM3B3YzBwVEpGcEFvCjZuWHU1WVk1SFlyVVBtcTU0ZzdmMTQ5a1ZDaEhINHp3cUpWOGJ1dEZTbW1BNDJuN3VtWC8zdFNQeTJYdWx1YmsKT0xHNVUyc0xhMEpGNDJJYlRzcjFWY0h1Zjh6Ui84VjhqR2x3dlpaOGRybzg0aGhSYjhkRE91UTRrOHhhZk1qQwpTWTNQYzFJU3NjNFJOTGpLcWlMWnhJNUVJQURuenBPWWg1SWFveS9ZRjFPcmhvYWhtc3hVaHpndkVPRXFvMVVmCjBRbHdPMjNXNC9IbkFOQ2JEY2Fwc2krOEtGT1BtdGM2eVozL0RMTkNucWI1TWFSZ0VwOFVoMjRZRjZzTDZmQ3MKRUwxZTBreUVlRUlQeTFQTFVFOXBpRENPNm1Yakp0ODEzMkx1bVlabnVJT3NXVHpZSlE9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcEFJQkFBS0NBUUVBM0l3aE5EeGdPZEp0TzVmN2lXdzJkck1ETXJZQ1oxTnF2b2ZLbStLT1Z3azJleGxyCk50UUJOWFVMN1Z5bmtQZzVOVWVER0czcTF1THp2SGR1TnBRV3NITUNQN3ROZGFLb1l4dkorbW5Cai82cnBaMUgKS0F0blJhbHRUWGNza2ZIVkoyNmNHYTBxVVpDVVd6Zy8rRVk4Y0M1L0NodXdrU3hucnA1UXRTaGhoVVB6MDdNawpkLzRLRm9DR0M0T1hLVWNCakVMaGlNeWVrbXlmZWJIUkJQVUNsM2lONndMbTB0NHZ2UzAvN2V1bm5hekJoa0hFClh1Yi9QRXpydEhsZysvSGQxVWtFMVVhZVgzdEZnMmVpdGMyZzJHZ0kvOXAvK3Vsd1c3c0Y1VnFRK0xoMzl5V0gKNE9NOGtnTnJCN0l0dG80ZXJpODY4ZUExejlSS0tVNE1sa05HTVFJREFRQUJBb0lCQUhoN2JPQTJZM0x6QzQxVQp0NnNaSEorM3AzV2FqTEdabG1URGxlR1c0SitYZnRXOHl4OUdyZXBnS01YZ3FnRytPTEpzZ0tkbDFMYlRnTWRpCmp5anR1WDluTk1GUU56NmVQMUwxS1YvTlNscTVpMWVNRmdWQVJZaCt5Q0ZiaTFPblF3U3Bua2xBbWkrNHhmTVgKUllzQ0E1NWRLRFdEYnUrL3pGeE9URlRLM0l1SjBmODFDOFQvdXR4L2ZrcUFQZ042enc3czg3STNKOXVoeEIrVwprNnpvVEI4dFdwT2hIdjFzWmFFRnRmK0NLQTN4dHE5SnZKaG1zVjdmUHRnVm00VkVyZHlNWlA3a2grM0JmY0tWCmdpSkR4YngvQ2FvQWtDOVdYNGxXVEFvVjJmN3J3OU5objNlV1AzQjlUaEUxYktGWTlKNkNseFZLb2dwYnd0MlAKZkZCM0lTa0NnWUVBNXVVTysybkV2Q1FwK2ZrL0RHcW9YdUpMOGxkbm41bkwzdVZOMEpIYnBnY1orcEM1bmwvVwp2bENPcEs1SWFzVXgrTmhNSUMxSmkvT2hLa09mcWZ4VzFhQ3pIMUZTZFF1NldxeXd4bzFrQThsV1R2bWZJQ2owCjM4dWxidDZFT1BZYXUvbzlHd2dsWFB3VUxBSHYwZXZONFJtaHpNOTRUazJHSk5HL1RLQkdGUThDZ1lFQTlJY04KYzJRbHAvUm92eHg1aVk5RGVrOEtIeVpWZHZiWHovalZ3Wll0NTVKOVhmMDBPa21lUFFCZDIrdzRNdUNQci9JMgo4S1V6SjA1eHJvb3o0bnN0bEZFT2h4ZURlcHg5OHlXaHU0SzFmblA4S09mcGxoUVFkWjgrbEtvUmVqSzJNcUpVCmdWRWRQUlJkQUYzZTNJSTRTRWY2RjFmZFZXZDJ4QktDcmtrTmNMOENnWUIwWFhxb2dJeXpHVExDbGJnTnhPOG8KS3JxRjMwRU5NWkNLdkZ2MFFwNUZWWXpsTiswa2dUNlQyYnVhQ1cvYng1aEF4cG5QR2FQWVVhZW15ai84aG4wbwoydjJMU2d2WmkxaVcvRE4zVGFqYk02dzR6eHRBTlFQOGlnRE5HSDNneXo5Ny8waXVoL04wb21KMEwyR3pGVGxFCk9ndk9VYjFiRVQwSzcxNk8rck4zUndLQmdRRFRvVTd5MzJuM3dvQWxadStKTG9Tb0JtQXNOWEVpVk9EVERmbHkKWWhlNG8vLzhxSGZiT252Skw5Z0x6cFdVOHVWbzBhamEvUjhZbGJ1dDQ4Nmo1UmU5bGFtTklieVpFWGV3U0pHQgpSODdzY2xWNjBieElOM1ZIVjF0Q0x5NlJJL0tzUC9JRE9jQ2tiRXRSVmV6Ynk1Z0tkc0RzRXc5c0t1K1BJcllYClFRSnc0UUtCZ1FEayszYkw2U0gydzcremx6cURCRi9HcWpkWWdsWDRBVEZnWVNtRFordlFUNFpsUFFZZjNIRlYKWlFEakhDS0xycjlBczFBejUzdHM1MmQ1V2gzcm1UNmxlVk9UUTBGeFdFMFFHa08vNDZ1RjlYSk9KZTh0R3FvdgprcjRBRVJYUUs5UTBYRzhEbnR0T2djd0s2aExiN0tPNE42UllPY2VDa3Q2TTl0am0vTlRaQ1E9PQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=

 

 

kubeconfig 의 구성은 크게 아래와 같습니다.

- cluster

- user

- context

 

cluster 는 kubectl 로 연결해야하는 Kubernetes Cluster 의 정보를 의미합니다.

cluster 는 name, server, certificate-authority-data 로 이루어집니다.

cluster.name 은 쿠버네티스 클러스터의 이름에 해당하는 메타데이터입니다.

cluster.server 은 쿠버네티스 클러스터의 ip 와 port 에 해당합니다.

그리고 cluster.certificate-authority-data 가 중요한데요.

cluster.certificate-authority-data 에는 인증서의 정보가 담깁니다.

쿠버네티스 클러스터는 CA Agent 로써 동작합니다.

즉, 쿠버네티스 클러스터는 상위 인증기관으로써 동작하게 되는 것이죠.

 

user 는 kubectl 을 사용하는 클라이언트를 의미합니다.

user 또한 name 과 certificate-authority-data 를 가지며,

certificate-key-data 를 추가적으로 가집니다.

user.name 은 클라이언트의 이름이구요.

user.certificate-authority-data 는 클라이언트가 사용하는 인증서 정보입니다.

그리고 user.certificate-key-data 는 인증서의 private key 가 됩니다.

 

context 는 user 와 cluster 의 조합이라고 생각하시면 됩니다.

contextAA : userA 로 clusterA 에 접근하겠다.

contextAB : userA 로 clusterB 에 접근하겠다.

contextCA : userC 로 clusterA 에 접근하겠다.

이런 느낌인 것이죠.

 

그래서 쿠버네티스는 어떻게 인증을 하는 것이냐 ?

하나의 User 와 하나의 Cluster 가 소통하기 위해서는 2개의 인증서가 필요합니다.

즉, 2개의 public key 와 2 개의 private key 가 필요하겠죠 ?

Cluster 가 가지는 public key, private key, 그리고 인증서가 각각 1개씩 존재합니다.

그리고 User 가 가지는 public key, private key, 그리고 인증서가 각각 1개씩 존재합니다. 

이들를 각각 이름을 짓도록 하겠습니다.

 

클러스터 private key : ca.key

클러스터 public key : ca.pub

클러스터 인증서 : ca.crt

 

사용자 private key : client.key

사용자 public key : client.pub

사용자 인증서 : client.crt

 

그리고 ca.crt 와 client.crt 의 CA 관계는 ca.crt 가 client.crt 를 signing 하고 있습니다.

즉, ca.crt 가 client.crt 의 상위 인증서인 것이죠.

 

kubeconfig 의 대략적인 구성은 아래와 같습니다.

 

clusters
	-cluster
    	name: test-cluster
        certificate-authority-data: ca.crt
users
	-user
    	name: test-user
        certificate-authority-data: client.crt
        certificate-key-data: client.key
contexts
	-context:
    	name: test-context
    	cluster: test-cluster
        user: test-user

 

위 상태에서 test-context 를 사용하면 test-user 와 test-cluster 간의 커뮤니케이션이 가능해집니다.

 

 

쿠버네티스 인증 과정 살펴보기.

인증 과정을 살펴보겠습니다.

kubectl 을 통해서 클러스터로 요청을 수행하게 되면,

kubectl 은 자신의 인증서인 client.crt 를 클러스터에게 제공합니다.

그럼 클러스터는 자신의 private key 인 ca.key 를 활용하여 client.crt 가 ca.crt 로 signing 한 인증서인지 검증하게 됩니다.

이러한 검증이 통과하게 된다면,

kubectl 을 통해서 user - cluster 간의 소통이 가능해지죠.

 

 

실습해보기.

클러스터의 인증서와 사용자의 인증서를 각각 생성합니다.

그리고 클러스터의 인증서가 사용자 인증서의 상위 인증서 관계를 취해야합니다.

 

< Cluster, User 의 인증서 생성 >

# Generate CA private key and certificate
openssl genpkey -algorithm RSA -out ca.key
openssl req -new -key ca.key -out ca.csr
openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt

# Generate client private key and certificate
echo 01 > ca.srl
openssl genpkey -algorithm RSA -out client.key
openssl req -new -key client.key -out client.csr
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -out client.crt

 

< 인증서들을 기반으로 Cluster, User 생성 >

아래 명령어들을 통해서 Cluster, User, Context 가 생성됩니다.

그리고 kubectl config user-context 를 통하여 새로운 context 를 활성화합니다.

kubectl config set-cluster my-cluster \
  --server=https://127.0.0.1:60662 \
  --certificate-authority=ca.crt \
  --embed-certs=true

kubectl config set-credentials my-user \
  --client-certificate=client.crt \
  --client-key=client.key \
  --embed-certs=true

kubectl config set-context my-context \
  --cluster=my-cluster \
  --user=my-user

kubectl config use-context my-context

 

 

kubeconfig 의 cluster 의 인증서가 실제 Kubernetes Cluster 의 인증서가 아니기 때문에 아래와 같이

signing 체크 단계에서 에러가 발생합니다.

 

kubectl get node 
E1212 10:07:27.675341   18650 memcache.go:265] couldn't get current server API group list: Get "https://127.0.0.1:60662/api?timeout=32s": tls: failed to verify certificate: x509: certificate signed by unknown authority
E1212 10:07:27.677858   18650 memcache.go:265] couldn't get current server API group list: Get "https://127.0.0.1:60662/api?timeout=32s": tls: failed to verify certificate: x509: certificate signed by unknown authority
E1212 10:07:27.680213   18650 memcache.go:265] couldn't get current server API group list: Get "https://127.0.0.1:60662/api?timeout=32s": tls: failed to verify certificate: x509: certificate signed by unknown authority
E1212 10:07:27.682626   18650 memcache.go:265] couldn't get current server API group list: Get "https://127.0.0.1:60662/api?timeout=32s": tls: failed to verify certificate: x509: certificate signed by unknown authority
E1212 10:07:27.685338   18650 memcache.go:265] couldn't get current server API group list: Get "https://127.0.0.1:60662/api?timeout=32s": tls: failed to verify certificate: x509: certificate signed by unknown authority