사용자 클러스터 인증 기관 순환

VMware용 GKE는 인증서 및 비공개 키를 사용하여 사용자 클러스터의 시스템 구성요소 간 연결을 인증하고 암호화합니다. 관리자 클러스터는 각 사용자 클러스터에 대해 새로운 인증 기관(CA) 집합을 만들고 이러한 CA 인증서를 사용하여 시스템 구성요소에 대해 추가적인 리프 인증서를 발급합니다. 관리자 클러스터는 보안 통신을 설정하기 위해 시스템 구성요소에 대한 공개 CA 인증서 및 리프 인증서 키 쌍의 배포를 관리합니다.

사용자 클러스터 CA 순환 기능을 사용하면 사용자 클러스터에서 핵심 시스템 인증서의 순환을 트리거할 수 있습니다. 순환 중 관리자 클러스터는 사용자 클러스터에 대해 핵심 시스템 CA를 새로 생성된 CA로 바꾸고, 새로운 공개 CA 인증서 및 리프 인증서 키 쌍을 사용자 클러스터 시스템 구성요소에 배포합니다. 순환이 증분적으로 발생하므로 순환 중에도 시스템 구성요소가 계속 통신할 수 있습니다. 하지만 순환 중에는 워크로드 및 노드가 다시 시작됩니다.

각 사용자 클러스터에 대해 관리자 클러스터에서 관리하는 시스템 CA는 세 가지입니다.

  • etcd CA는 API 서버에서 etcd 복제본으로의 통신과 etcd 복제본 간 트래픽도 보호합니다. 이 CA는 자체 서명됩니다.
  • 클러스터 CA는 API 서버와 모든 내부 Kubernetes API 클라이언트(kubelet, 컨트롤러, 스케줄러) 간의 통신을 보호합니다. 이 CA는 자체 서명됩니다.
  • 프런트 프록시 CA는 집계된 API와의 통신을 보호합니다. 이 CA는 자체 서명됩니다.

추가적으로 조직 CA를 사용하여 authentication.sni 옵션으로 구성된 인증서를 서명할 수 있습니다. 이 CA와 SNI 인증서는 클러스터 외부의 클라이언트에 Kubernetes API를 제공하기 위해 사용됩니다. 이 CA를 관리하고 SNI 인증서를 수동으로 생성합니다. 이 CA 또는 SNI 인증서 모두 사용자 클러스터 CA 순환 기능의 영향을 받지 않습니다.

제한사항

  • 사용자 클러스터 CA 순환 기능은 VMware용 Anthos 클러스터 버전 1.8 이상에서 지원됩니다.
  • 사용자 클러스터 CA 순환 기능은 특히 개요에 설명된 etcd, 클러스터, 프런트 프록시 CA로 제한됩니다. 조직 CA는 순환하지 않습니다. 사용자 클러스터 CA 순환 기능은 또한 VMware용 Anthos 클러스터에서 자동으로 발급된 인증서로 제한됩니다. 해당 인증서가 시스템 CA에서 서명된 경우에도 관리자가 수동으로 발급한 인증서는 업데이트하지 않습니다.
  • CA 순환을 위해서는 API 서버, 제어 영역 프로세스, 클러스터의 각 노드를 여러 번 다시 시작해야 합니다. CA 순환의 각 단계는 클러스터 업그레이드와 비슷하게 진행됩니다. CA가 순환되는 동안 사용자 클러스터가 작동 상태로 유지되지만 워크로드가 다시 시작되고 다시 예약된다는 것에 주의해야 합니다. 또한 HA 구성을 사용하지 않을 때 제어 영역이 짧은 기간 동안 작동 중지됩니다.
  • 사용자 클러스터에 연결하기 위한 사용자 클러스터 kubeconfig 파일 및 인증 구성 파일은 CA 순환에 따라 수동으로 업그레이드 및 재배포되어야 합니다. 이것은 CA 순환으로 인해 이전 CA가 필수적으로 해지되므로, 이러한 사용자 인증 정보로 더 이상 인증되지 않기 때문입니다.
  • 시작된 후에는 CA 순환을 일시 중지하거나 롤백할 수 없습니다.
  • CA 순환은 사용자 클러스터 크기에 따라 완료되는 데 시간이 오래 걸릴 수 있습니다.

CA 순환 수행 방법

CA 순환을 시작하고 아래 gkectl 명령어를 실행하여 현재 순환 상태를 확인할 수 있습니다.

CA 인증서 순환

CA 순환을 트리거하려면 다음 명령어를 실행합니다.

gkectl update credentials certificate-authorities rotate \
--config USER_CONFIG_FILE \
--kubeconfig ADMIN_KUBECONFIG_FILE

각 항목의 의미는 다음과 같습니다.

  • USER_CONFIG_FILE은 CA를 순환하기 위한 사용자 클러스터의 사용자 클러스터 구성 파일 경로입니다.
  • ADMIN_KUBECONFIG_FILE은 사용자 클러스터를 관리하는 관리자 클러스터에 연결하기 위한 kubeconfig 파일의 경로입니다.

CA 순환이 성공적으로 시작되었으면 다음과 비슷한 메시지가 표시됩니다.

successfully started the CA rotation with CAVersion 2, use gkectl update credentials certificate-authorities status command to view the current state of CA rotation

CA 순환이 이미 진행 중이면 다음과 비슷한 오류 메시지가 표시됩니다.

Exit with error:
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request: requests must not modify CAVersion when cluster is not ready: ready condition is not true: ClusterCreateOrUpdate: Creating or updating user cluster control plane workloads

CA 순환 상태 보기

CA 순환 상태를 보려면 다음 명령어를 실행합니다. 이 명령어는 시스템이 각 CA 순환 이전 및 이후에 사용되는 CA를 구분하기 위해 자동으로 증분시키는 정수인 CAVersion, CA 순환이 완료되었는지 여부를 나타내는 상태(True 또는 False), 시스템의 각 구성요소에서 현재 사용 중인 CAVersion을 기술하는 메시지를 보고합니다.

gkectl update credentials certificate-authorities status \
--config USER_CONFIG_FILE \
--kubeconfig ADMIN_KUBECONFIG_FILE

CA 순환이 이미 완료되었으면 다음과 비슷한 메시지가 표시됩니다.

State of CARotation with CAVersion 2 is -
status: True,
reason: CARotationCompleted,
message: Control plane has CA bundle [2], certs from CA 2, CA 2 is CSR signer. Data plane has CA bundle [2], CA 2 was CSR signer at last restart.

CA 순환이 아직 진행 중이면 다음과 비슷한 메시지가 표시됩니다.

State of CARotation with CAVersion 2 is -
status: False,
reason: CARotationProgressed,
message: Control plane has CA bundle [1 2], certs from CA 2, CA 1 is CSR signer. Data plane has CA bundle [1 2], CA 1 was CSR signer at last restart.

사용자 클러스터 인증서 업데이트

CA 순환이 완료되면 사용자 클러스터에 연결하기 위해 이전에 사용된 이전 kubeconfig를 대체하도록 관리자 클러스터에서 새로운 사용자 클러스터 kubeconfig 파일을 다운로드해야 합니다. 이것은 CA 순환으로 인해 이전 kubeconfig 파일의 기준이 되는 이전 CA가 해지되기 때문입니다. CA 순환이 완료된 후 다음 명령어를 실행하여 새 kubeconfig 파일을 다운로드합니다.

kubectl --kubeconfig ADMIN_KUBECONFIG_FILE get secret admin \
 -n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
 | base64 --decode > USER_CLUSTER_NAME-kubeconfig

추가 kubeconfig 파일이 클러스터의 다른 사용자에게 수동으로 발급된 경우에도 이를 업데이트해야 합니다.

인증 구성 파일 업데이트

CA 순환이 완료되면 인증 구성 파일을 업데이트하고 다시 배포해야 합니다. CA 순환 후 연결된 안내에 따라 이러한 파일을 업데이트하고 다시 배포하세요.

제어 영역 인증서 순환

순환이 없으면 사용자 클러스터 CA 및 제어 영역 인증서 모두 클러스터가 생성된 날로부터 5년 후에 만료됩니다. 사용자 클러스터의 제어 영역 인증서는 각 사용자 클러스터 업그레이드 후 10시간 이내에 자동으로 순환되지만 CA는 자동으로 순환되지 않습니다. 즉, 일반 버전 업그레이드 외에도 최소 5년마다 한 번씩 CA 순환을 수행해야 합니다.

사용자 클러스터를 사용할 수 없게 되지 않도록 제어 영역 인증서는 사용자 클러스터 업그레이드 후 10시간 이내에 순환됩니다. 이 경우 사용자 클러스터의 CA 순환 상태에 메시지가 표시됩니다.

제어 영역 인증서가 순환될 때 사용자 클러스터가 업그레이드된 마지막 버전을 보려면 다음을 실행합니다.

gkectl update credentials certificate-authorities status \
--config USER_CONFIG_FILE \
--kubeconfig ADMIN_KUBECONFIG_FILE

사용자 클러스터가 최근에 버전 1.10 이상으로 업그레이드된 경우 10시간 이내에 message 필드 끝에 메시지가 표시됩니다. 예를 들면 다음과 같습니다.

Last Leaf Certificates Rotation Version: 1.10.0-gke.0.

CA 순환 문제 해결

gkectl diagnose 명령어는 사용자 클러스터에 대해 완료된 CA 순환의 예상 상태를 확인하도록 지원합니다. 사용자 클러스터에 대해 gkectl을 실행하는 방법은 클러스터 문제 진단을 참조하세요. CA 순환에 문제가 있으면 Google 지원팀에 문의하고 gkectl diagnose 출력을 제공하세요.