Udemy CKA 강의 정리 144: TLS in Kubernetes

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.

---

이번 강의에서는 TLS 인증서로 Kubernetes 클러스터를 보호하는 방법을 살펴봅니다. 이전 강의에서 public 키와 private 키가 무엇인지, 서버가 public 및 private 키를 사용하여 연결을 보호하는 방법에 대해 살펴보았습니다. 이를 server certificates 라고 합니다.

Certificate Authority 이 무엇인지 살펴보았습니다. 우리는 CA가 서버 인증서에 서명하는 데 사용하는 자체 public 및 private  키 페어 세트를 가지고 있음을 배웠습니다. 이를 root certificates라고 합니다.

또한 서버가 client certificates를 사용하여 자신을 확인하도록 클라이언트에 요청하는 방법도 살펴보았습니다.

따라서 세 가지 유형의 인증서가 있습니다.

- 서버에 구성된 서버 인증서

- CA 서버에 구성된 루트 인증서

- 클라이언트에 구성된 클라이언트 인증서

계속 진행하기 전에 명명 규칙에 대해 간단히 알아 보겠습니다. 이 강의에서 많은 인증서 파일을 보게 될 것이며 매우 혼란스러울 수 있습니다. 따라서 명명규칙을 알고 있다면 인증서를 구분할 수 있습니다.

일반적으로 public 키가 있는 인증서는 .crt 또는 .pem 확장자로 지정됩니다. 서버 인증서의 경우는 server.crt 또는 server.pem 와 같은 이름을 씁니다. 클라이언트 인증서는 client.crt나 client.pem을 사용합니다.

private키는 일반적으로 이름에 '-key'가 있습니다. 예를 들어, server.key , server-key.pem과 같습니다. 따라서 private 키에는 일반적으로 확장자나 인증서 이름에 key라는 단어가 포함되어 있다는 점을 기억하세요. key 단어가 없는 것은 일반적으로 public 키 또는 인증서입니다.

이제 이러한 개념이 Kubernetes 클러스터와 어떻게 관련되는지 살펴보겠습니다. Kubernetes 클러스터는 마스터 및 워커 노드 세트로 구성됩니다. 물론 이러한 노드 간의 모든 통신은 안전해야 하며 암호화되어야 합니다. 모든 서비스와 클라이언트 간의 모든 상호 작용은 안전해야 합니다. 예를 들어 kubectl 유틸리티를 통해 또는 Kubernetes API에 직접 액세스하는 동안 Kubernetes 클러스터와 상호 작용하는 관리자는 보안 TLS 연결을 설정해야 합니다. Kubernetes 클러스터 내의 모든 컴포넌트 간의 통신도 보호되어야 합니다. 따라서 두 가지 기본 요구 사항은 서버 인증서를 사용하는 클러스터 내의 모든 다양한 서비스를 갖는 것과 클라이언트 인증서를 사용하여 자신이 누구인지 확인하는 모든 클라이언트를 갖는 것입니다.

• Server Certificates for Servers
• Client Certificates for Clients

Kubernetes 클러스터 내의 다양한 컴포넌트를 살펴보겠습니다. 다양한 서버와 클라이언트를 식별하고, 누가 누구와 대화하는지 살펴보겠습니다.

kube-apiserver부터 시작하겠습니다. 이미 알고 있듯이 API 서버는 다른 컴포넌트와 외부 사용자가 Kubernetes 클러스터를 관리하는 데 사용하는 https 서비스를 노출합니다. 따라서 API서버는 서버이며, 클라이언트와의 모든 통신을 보호하려면 인증서가 필요합니다. 따라서 인증서와 키 쌍을 생성합니다. 이를 APIserver.cert 및 APIserver.key라고 합니다. 앞으로 이 명명 규칙을 고수하려고 노력할 것입니다. .crt 확장자는 인증서이며,  .key 확장자는 private 키입니다.

또한 이러한 인증서 이름은 Kubernetes 설정과 클러스터를 누가 어떻게 설정했는지에 따라 다를 수 있습니다. 따라서 강의에서 보여지는 이름은 각자 환경의 이름과 다를 수 있습니다. 이 강의에서는 인증서 파일을 쉽게 식별할 수 있는 이름을 사용하려고 합니다.

클러스터에 있는 또 다른 서버는 etcd 서버입니다. etcd 서버는 클러스터에 대한 모든 정보를 저장합니다. 따라서 한 쌍의 인증서와 키가 필요합니다. 우리는 그것을 etcdserver.crt 및 etcdserver.key라고 부릅니다.

클러스터에 있는 또 다른 서버 컴포넌트는 워커 노드에 있습니다. 바로 kubelet 서비스입니다. 그들은 또한 kube-apiserver가 워커 노드와 상호 작용하기 위해 통신하는 HTTPS API 엔드포인트를 expose합니다. 다시 말하지만 인증서와 키 쌍이 필요합니다. 우리는 이를 kubelet.cert와 kubelet.key.라고 부릅니다. 지금까지 Kubernetes 클러스터의 서버 컴포넌트를 살펴보았습니다.

이제 클라이언트 컴포넌트를 살펴보겠습니다. 이러한 서비스에 액세스하는 클라이언트는 누구입니까? kube-apiserver에 접근하는 클라이언트는 kubectl Arrest API(?)를 통해 관리하는 관리자인 우리들입니다. admin 사용자는 kube-API 서버에 인증하기 위해 인증서와 키 쌍이 필요합니다. admin.crt 및 admin.key라고 하겠습니다.

스케줄러는 kube-apiserver와 통신하여 스케쥴링이 필요한 파드를 찾은 다음 API 서버가 올바른 워커 노드에서 파드를 예약하도록 합니다. 스케줄러는 kube-apiserver에 액세스하는 클라이언트입니다. kube-apiserver에 관련되어 생각했을 때, 스케줄러는 admin 사용자와 같은 또 다른 클라이언트일 뿐입니다. 따라서 스케줄러는 클라이언트 TLS 인증서를 사용하여 identity를 검증해야 합니다. 따라서 자체 인증서와 키 쌍이 필요합니다. 우리는 이를 scheduler.cert 와 scheduler.key라고 부를 것입니다.

Kube Controller Manager는 kube-apiserver에 액세스하는 또 다른 클라이언트이므로 kube-apiserver에 대한 인증을 위한 인증서도 필요합니다. 따라서 이에 대한 인증서 쌍을 생성합니다.

마지막 클라이언트 컴포넌트는 kube-proxy입니다. kube-proxy는 kube-apiserver에 인증하기 위해 클라이언트 인증서가 필요하므로 자체 인증서 및 키 쌍이 필요합니다. 이를 kubeproxy.crt 및 kubeproxy.key라고 합니다.

서버들은 그들 사이에서도 통신합니다. 예를 들어 kube-apiserver는 etcd 서버와 통신합니다. 실제로 모든 컴포넌트 중에서 kube-apiserver는 etcd 서버와 통신하는 유일한 서버입니다. 따라서 etcd 서버에서 생각해보면 kube-apiserver는 클라이언트이므로 인증이 필요합니다. kube-apiserver는 자체 API 서비스를 제공하기 위해 이전에 사용한 것과 동일한 키를 사용할 수 있습니다. APIserver.crt 및 APIserver.key 파일입니다. 또는 kube-apiserver가 etcd 서버에 인증할 수 있도록 특별히 새 인증서 쌍을 생성할 수 있습니다.

kube-apiserver는 또한 워커 노드를 모니터링하기 위해 각 개별 노드에서 kubelet 서버와 통신합니다. 다시 말하지만 원래 인증서를 사용하거나 특별히 이 목적을 위해 새 인증서를 생성할 수 있습니다.

이렇게 생긴 인증서가 너무 많습니다. 그룹지어 보겠습니다. 클라이언트가 kube-apiserver에 연결하기 위해 주로 사용하는 client certificates 세트가 있고, kube-apiserver, etcd 서버 및 kublet이 클라이언트를 인증하는 데 사용하는 server site certificates 세트가 있습니다. 

이제 이러한 인증서를 생성하는 방법을 살펴보겠습니다. 이미 알고 있듯이 이러한 모든 인증서에 서명하려면 인증 기관(certificate authority)이 필요합니다. Kubernetes는 클러스터에 대해 적어도 하나 이상의 certificate authority을 요구합니다. 실제로 둘 이상을 가질 수 있습니다. 하나는 클러스터의 모든 컴포넌트용이고 다른 하나는 특별히 etcd용입니다. 이 경우 etcd 서버 인증서와 etcd 서버 클라이언트 인증서(이 경우 API 서버 클라이언트 인증서)는 모두 etcd 서버 CA에서 서명됩니다. 지금은 클러스터에 대해 하나의 CA만 사용할 것입니다. 우리가 알고 있듯이 CA에는 자체 인증서와 키 쌍이 있습니다. 우리는 그것을 ca.crt 및 ca.key라고 부를 것입니다. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

를 생성하는 방법을 살펴보겠습니다. 이미 알고 있듯이 이러한 모든 인증서에 서명하려면 인증 기관이 필요합니다. Kubernetes를 사용하려면 클러스터에 대해 하나 이상의 인증 기관이 있어야 합니다. 실제로 둘 이상을 가질 수 있습니다. 하나는 클러스터의 모든 컴포넌트용이고 다른 하나는 특별히 etcd용입니다. 이 경우 etcd 서버 인증서와 etcd 서버 클라이언트 인증서(이 경우 API 서버 클라이언트 인증서)는 모두 etcd 서버 CA에서 서명됩니다. 지금은 클러스터에 대해 하나의 CA만 사용할 것입니다. 우리가 알고 있듯이 CA에는 자체 인증서와 키 쌍이 있습니다. 우리는 그것을 CA.crt 및 CA.key라고 부를 것입니다. 그러면 클러스터에서 사용되는 모든 인증서가 요약됩니다.