Udemy CKA 강의 정리 150: Certificates API

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

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

---

이번 강의에서는 인증서를 관리하는 방법과 쿠버네티스에서 인증서 API가 무엇인지 살펴봅니다.

그래서 우리는 지금까지 무엇을 했나요? 우리는 클러스터의 관리자로서 전체 클러스터를 설정하는 과정에서 CA 서버와 다양한 컴포넌트에 대한 인증서를 설정했습니다. 그런 다음 올바른 인증서를 사용하여 서비스를 시작했고 지금은 모든 것이 작동하고 있습니다. 우리는 클러스터의 유일한 관리자이자 사용자이며 자신의 관리자 인증서와 키를 가지고 있습니다.

새 관리자가 우리 팀에 들어왔습니다. 그녀는 클러스터에 대한 액세스 권한이 필요합니다. 우리는 그녀가 클러스터에 액세스할 수 있도록 한 쌍의 인증서와 키 쌍을 가져와야 합니다. 그녀는 자신의 private key를 만들고 인증서 서명 요청을 생성하여 우리에게 보냅니다. 우리는 유일한 관리자이므로 우리의 CA 서버로 인증서 서명 요청을 받고 CA 서버의 private key와 경로 인증서를 사용하여 CA 서버에서 서명을 받아 인증서를 생성한 다음, 인증서를 그녀에게 다시 보냅니다. 이제 그녀는 클러스터에 액세스하는 데 사용할 수 있는 유효한 인증서와 키 쌍을 갖게 되었습니다.

인증서에는 유효 기간이 있습니다. 일정 시간이 지나면 종료됩니다. 만료될 때마다 새로운 CSR을 생성하고 CA의 서명을 받는 동일한 프로세스를 따릅니다. 이렇게 인증서 파일을 계속 교체합니다.

CA (Certificate Authority)

CA 서버에 대한 얘기가 계속 나왔습니다. CA 서버는 무엇이며 Kubernetes 설정에서 어디에 위치해 있을까요? CA는 우리가 생성한 키와 인증서 파일의 쌍입니다. 이 파일 쌍에 대한 액세스 권한을 얻은 사람은 누구나 Kubernetes 환경에 대한 모든 인증서에 서명할 수 있습니다. 원하는 권한을 원하는 만큼 사용자를 생성할 수 있습니다. 따라서 이러한 파일은 안전한 환경에서 보호되고 저장되어야 합니다. 완전히 안전한 서버에 배치한다고 가정해 보겠습니다. 이제 해당 서버가 CA 서버가 됩니다. 인증서 키 파일은 해당 서버에만 안전하게 저장됩니다. 인증서에 서명할 때마다 해당 서버에 로그인해야만 서명할 수 있습니다.

현재 Kubernetes 마스터 노드 자체에 인증서가 있으므로, 마스터 노드도 CA 서버입니다. Kubeadm tool은 동일한 작업을 수행합니다. CA 파일 쌍을 생성하고 마스터 노드 자체에 저장합니다.

지금까지는 수동으로 요청에 서명했지만 사용자가 증가하고 팀이 성장함에 따라 인증서, 서명 요청을 관리하고 만료 시 인증서를 교체하는 더 나은 자동화 방법이 필요합니다.

Kubernetes에는 이를 수행할 수 있는 인증서 API가 builtin되어 있습니다. 이제 인증서 API를 사용하여 API 호출을 통해 Kubernetes에 직접 인증서 서명 요청을 보냅니다.

- 이번에는 관리자가 인증서 서명 요청을 받으면 마스터 노드에 로그온하여 인증서에 직접 서명하는 대신에, 인증서 서명 요청이라는 Kubernetes API 오브젝트를 생성합니다.

- 오브젝트가 생성되면 클러스터 관리자가 모든 인증서 서명 요청을 볼 수 있습니다. Kubectl 커맨드를 사용하여 요청을 쉽게 검토하고 승인할 수 있습니다.

- 그런 다음 이 인증서를 추출하여 사용자와 공유할 수 있습니다.

어떻게 수행되는지 봅시다. 사용자는 먼저 키를 만든 다음 자신의 이름이 있는 키를 사용하여 인증서 서명 요청을 생성한 다음 요청을 관리자에게 보냅니다.

$ openssl genrsa -out jane.key 2048

$ openssl req -new -key jane.key -subj "/CN=jane" -out jane.csr

관리자는 키를 가져와 인증서 서명 요청 오브젝트를 만듭니다. 인증서 서명 요청 오브젝트는 일반 필드가 있는 매니페스트 파일을 사용하여 다른 Kubernetes 오브젝트와 마찬가지로 생성됩니다.

apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
  name: jane
spec:
  groups:
  - system:authenticated
  usages:
  - digital signature
  - key encipherment
  - server auth
  request:
    <certificate-goes-here>

kind는 CertificateSigningRequest입니다. spec 섹션에서 사용자가 속해야 하는 그룹을 지정하고 usage 들도 지정해줍니다. request 필드는 사용자가 보낸 인증서 서명 요청을 지정합니다. 여기에서 일반 텍스트가 아닌 base 64 커맨드를 사용하여 인코딩해야 한 CSR을 입력해야 합니다. 

오브젝트가 생성되면 관리자는 Kubectl get csr 커맨드를 실행하여 모든 인증서 서명 요청을 볼 수 있습니다.

$ kubectl get csr

kubectl certificate approve 커맨드를 실행하여 새 요청을 식별하고 요청을 승인합니다.

$ kubectl certificate approve jane

Kubernetes는 CA 키 쌍을 사용하여 인증서에 서명하고 사용자를 위한 인증서를 생성합니다.

그런 다음 이 인증서를 추출하여 사용자와 공유할 수 있습니다. YAML 형식으로 확인하여 인증서를 봅니다. 

$ kubectl get csr jane -o yaml

생성된 인증서는 Base 64 로 인코딩된 형식입니다. 디코딩하려면 텍스트를 가져와서 base 64  --decode 옵션을 사용하십시오.

$ echo "<certificate>" |base64 --decode

이렇게 하면 일반 텍스트 형식의 인증서를 제공합니다. 그런 다음 최종 사용자와 공유할 수 있습니다.

이제 어떻게 작동하는지 살펴보았으니 어떤 것이 이 모든 일을 하는지 살펴 봅시다. Kubernetes 컨트롤 플레인을 보면 Kube API 서버,스케줄러, Controller Manager, CD 서버 등이 보입니다.

이러한 컴포넌트 중 실제로 모든 인증서 관련 작업을 담당하는 컴포넌트는 무엇일까요? 모든 인증서 관련 작업은 Controller Manager가 수행합니다. Controller Manager를 자세히 살펴보면 CSR 승인, CSR 서명 등의 특정 작업을 수행하는 컨트롤러가 있음을 알 수 있습니다.

누군가가 인증서에 서명해야 하는 경우 CA 서버 루트 인증서와 private key가 필요합니다.Controller Manager service configuration에는 이를 지정할 수 있는 두 가지 옵션이 있습니다.