이 페이지에서는 클러스터 관리자와 보안 엔지니어가 GKE 컨트롤 플레인 권한에 대해 구성한 인증 기관 (CA)과 서비스 계정 서명 키를 순환하는 방법을 보여줍니다.
다음 개념을 잘 알고 있어야 합니다.
사용자 인증 정보 순환 계획
이 페이지에서는 컨트롤 플레인에서 다음 사용자 인증 정보 구성요소를 순환하는 방법을 보여줍니다.
- 클러스터 루트 CA, 집계 루트 CA, etcd API 루트 CA, etcd 피어 루트 CA
- Kubernetes ServiceAccount 서명 및 확인 키입니다.
컨트롤 플레인 부팅 디스크, etcd 디스크, 재해 복구에 Google Cloud 사용되는 etcd 내부 백업을 암호화하는 데 사용한 고객 관리 암호화 키를 순환할 수도 있습니다. 자세한 내용은 etcd 및 컨트롤 플레인 부팅 디스크 암호화 키 순환을 참고하세요.
CA 만료를 방지하고, 키 버전 손상을 완화하고, 조직의 보안 관행의 일환으로 사용자 인증 정보를 순환하세요. 특정 GKE control plane authority 리소스를 얼마나 자주 순환할지 계획하려면 다음을 고려하세요.
- 기본적으로 Certificate Authority Service (CA 서비스)의 루트 CA에서 서명한 GKE 인증서는 생성일로부터 1년 후에 만료됩니다.
- Cloud Key Management Service (Cloud KMS)의 키는 만료되지 않습니다. 조직에 키 순환 요구사항이 있는 경우에만 수동 키 순환을 실행합니다. 실행 중인 워크로드의 중단을 최소화하려면 이러한 키에 대해 자동 키 순환을 구성하지 마세요.
시작하기 전에
시작하기 전에 다음 태스크를 수행했는지 확인합니다.
- Google Kubernetes Engine API를 사용 설정합니다. Google Kubernetes Engine API 사용 설정
- 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화하세요. 이전에 gcloud CLI를 설치한 경우
gcloud components update를 실행하여 최신 버전을 가져옵니다.
자체 관리 CA 및 서비스 계정 키를 사용하는 기존 클러스터가 있어야 합니다.
다음 Google Cloud 프로젝트의 프로젝트 ID를 확인합니다.
- 키 프로젝트: Cloud KMS 및 CA 서비스 리소스가 포함된 프로젝트입니다.
- 클러스터 프로젝트: GKE 클러스터가 포함된 프로젝트입니다.
이 페이지에서 검증 작업을 수행하려면 다음 데이터 액세스 감사 로그가 사용 설정되어 있는지 확인하세요.
- Cloud Key Management Service(KMS) API:
DATA_READ - Certificate Authority Service:
ADMIN_READ
이러한 로그 유형을 사용 설정하려면 데이터 액세스 감사 로그 사용 설정을 참고하세요.
- Cloud Key Management Service(KMS) API:
필수 역할 및 권한
고객 관리 CA 및 키를 순환하는 데 필요한 권한을 얻으려면 관리자에게 다음 IAM 역할을 부여해 달라고 요청하세요.
-
키 또는 키 버전 관리: 키 프로젝트에 대한 Cloud KMS 관리자 (
roles/cloudkms.admin) -
루트 CA 관리:
키 프로젝트에 대한 CA Service 관리자 (
roles/privateca.admin) -
새 사용자 인증 정보를 사용하도록 클러스터 구성:
클러스터 프로젝트에 대한 Kubernetes Engine 클러스터 관리자 (
roles/container.clusterAdmin)
역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.
커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.
제한사항
서비스 계정 서명 및 확인에 사용하는 비대칭 Cloud KMS 키는 자동 키 순환을 지원하지 않습니다.
서비스 계정 서명 및 확인 키 순환
GKE 컨트롤 플레인 권한을 설정할 때 서비스 계정 서명 키와 서비스 계정 확인 키를 클러스터에 추가합니다. GKE는 이러한 키를 사용하여 Kubernetes ServiceAccount의 Bearer 토큰을 서명하고 검증합니다. 순환 중에 서비스 계정 확인 키 목록에 새 키를 추가하고 변경사항이 전파될 때까지 기다린 다음 서비스 계정 서명 키를 새 키로 바꿉니다.
서비스 계정 키를 순환하려면 다음 단계를 따르세요.
서비스 계정 서명 키의 원래 키 버전의 전체 리소스 이름을 가져옵니다.
gcloud container clusters describe CLUSTER_NAME \ --project=CLUSTER_PROJECT_ID \ --location=CONTROL_PLANE_LOCATION \ --format="value(userManagedKeysConfig.serviceAccountSigningKeys)"다음을 바꿉니다.
CLUSTER_NAME: 클러스터 이름입니다.CONTROL_PLANE_LOCATION: 클러스터의 위치입니다.CLUSTER_PROJECT_ID: 클러스터 프로젝트의 프로젝트 ID입니다.
출력은 다음과 비슷합니다.
projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/SIGNING_KEY_NAME/cryptoKeyVersions/ORIGINAL_SIGNING_KEY_VERSION이 출력에서
SIGNING_KEY_NAME는 키의 이름이고ORIGINAL_SIGNING_KEY_VERSION는 원래 서명 키 버전의 번호입니다.서비스 계정 서명 키의 새 키 버전을 만듭니다.
gcloud kms keys versions create \ --key=SIGNING_KEY_NAME \ --keyring=KEYRING_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_ID다음을 바꿉니다.
SIGNING_KEY_NAME: 서비스 계정 서명 키의 이름입니다.KEYRING_NAME: 키가 저장된 키링의 이름입니다.CONTROL_PLANE_LOCATION: 키링의 Google Cloud 위치입니다.KEY_PROJECT_ID: 키 프로젝트의 프로젝트 ID
새 키 버전의 전체 리소스 이름을 가져옵니다.
gcloud kms keys versions list \ --key=SIGNING_KEY_NAME \ --keyring=KEYRING_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_ID \ --filter="STATE=ENABLED" --sort-by=~ \ --format="value(name)" | sed 1q출력은 다음과 비슷합니다.
projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/SIGNING_KEY_NAME/cryptoKeyVersions/NEW_SIGNING_KEY_VERSION이 출력에서
SIGNING_KEY_NAME은 키의 이름이고NEW_SIGNING_KEY_VERSION은 새 서명 키 버전의 번호입니다.클러스터의 서비스 계정 확인 키 집합에 새 키 버전을 추가합니다.
gcloud container clusters update CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=CLUSTER_PROJECT_ID \ --service-account-verification-keys=ORIGINAL_KEY_VERSION_PATH,NEW_KEY_VERSION_PATH다음을 바꿉니다.
ORIGINAL_KEY_VERSION_PATH: 이 섹션의 첫 번째 단계 출력에 있는 원래 서명 키 버전의 전체 리소스 이름입니다. 예를 들면projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/1입니다.NEW_KEY_VERSION_PATH: 이전 단계의 출력에 있는 새 서명 키 버전의 전체 리소스 이름입니다. 예를 들면projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/2입니다.
클러스터 업데이트 작업이 완료된 후 새 키 버전 경로가 Kubernetes API 서버와 모든 GKE API 엔드포인트에 전파되는 데 최대 10분이 걸릴 수 있습니다.
새 키 버전 경로가 완전히 전파되었는지 확인하려면 다음 단계를 따르세요.
GKE API에서 클러스터 서명 키의 공개 구성요소를 JSON 웹 키 세트 (JWKS)로 가져옵니다.
curl https://container.googleapis.com/v1/projects/CLUSTER_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/jwks출력은 다음과 비슷합니다.
{ "keys": [ { "kty": "RSA", "alg": "RS256", "use": "sig", "kid": "KEY1_ID", "n": "KEY1_MODULUS", "e": "KEY1_EXPONENT" }, { "kty": "RSA", "alg": "RS256", "use": "sig", "kid": "KEY2_ID", "n": "KEY2_MODULUS", "e": "KEY2_EXPONENT" } ] }이 출력에는 키 항목이 두 개 있어야 합니다. 이는 두 키 버전을 모두 GKE API에서 사용할 수 있음을 나타냅니다. 키 항목이 하나만 표시되면 10분 동안 기다린 후 명령어를 다시 시도하세요.
kubectl명령어를 실행할 수 있도록 클러스터에 연결합니다.gcloud container clusters get-credentials CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATIONKubernetes API 서버에서 클러스터 서명 키의 공개 구성요소를 JWKS로 가져옵니다.
kubectl get --raw /openid/v1/jwks | jq출력은 다음과 비슷합니다.
{ "keys": [ { "kty": "RSA", "alg": "RS256", "use": "sig", "kid": "KEY1_ID", "n": "KEY1_MODULUS", "e": "KEY1_EXPONENT" }, { "kty": "RSA", "alg": "RS256", "use": "sig", "kid": "KEY2_ID", "n": "KEY2_MODULUS", "e": "KEY2_EXPONENT" } ] }이 출력에는 키 버전이 모두 Kubernetes API 서버에서 사용 가능함을 나타내는 두 개의 키 항목이 있어야 합니다. 키 항목이 하나만 표시되면 10분 동안 기다린 후 명령어를 다시 시도하세요.
새 키 버전을 서비스 계정 서명 키로 사용하도록 클러스터를 업데이트합니다.
gcloud container clusters update CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=CLUSTER_PROJECT_ID \ --service-account-signing-key=NEW_KEY_VERSION_PATH새 서비스 계정 토큰이 새 키 버전을 사용하는지 확인합니다.
ServiceAccount를 만듭니다.
kubectl create serviceaccount test-sa-1ServiceAccount의 토큰을 만듭니다.
kubectl create token test-sa-1Logging에서 최근에 서명된 다이제스트를 추출합니다.
export SIGNED_DIGEST=$(gcloud logging read \ 'resource.type="gke_cluster" '\ 'AND resource.labels.cluster_name="' CLUSTER_NAME '" '\ 'AND protoPayload.methodName="google.cloud.gkeauth.v1.Auth.SignServiceAccountJWT" '\ 'AND protoPayload.metadata.subject="system:serviceaccount:default:test-sa-1"' \ --freshness=1h \ --bucket=_Required \ --location=global \ --view=_AllLogs \ --order=DESC \ --limit=1 \ --format="value(protoPayload.metadata.toBeSignedDigest)")- 새 서명 키 버전이 사용 중인지 확인합니다.
gcloud logging read \ 'resource.type="cloudkms_cryptokeyversion" '\ 'AND protoPayload.methodName="AsymmetricSign" '\ 'AND protoPayload.request.digest.sha256="'${SIGNED_DIGEST}'"' \ --freshness=1h \ --bucket=_Default \ --location=global \ --view=_AllLogs \ --order=DESC \ --limit=1 \ --format="value(protoPayload.resourceName)" ``` The output is the resource path of the new signing key version.
원래 서비스 계정 서명 키 버전을 사용하는 클러스터의 모든 토큰이 만료될 때까지 기다립니다. 기본적으로 토큰 수명은 1시간이며, 최대 24시간까지 구성할 수 있습니다. 클러스터에서 구성된 토큰 수명을 확인하려면 다음 명령어를 실행하세요.
kubectl get pods -A -o json | jq -r '.items[]?.spec?.volumes[]?.projected?.sources[]?.serviceAccountToken?.expirationSeconds | select(. != null)' | sort -nr | head -n 1이전 단계의 출력에서 구성된 토큰 수명이 지날 때까지 기다립니다. 이 기간이 지나면 클러스터의 모든 바인드된 토큰이 새 서비스 계정 서명 키 버전을 사용합니다.
클러스터의 인증 키 목록에서 원래 키 버전을 삭제합니다.
gcloud container clusters update CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=CLUSTER_PROJECT_ID \ --service-account-verification-keys=NEW_KEY_VERSION_PATH선택사항: 원래 키 버전을 사용 중지합니다. 원래 키 버전이 사용되지 않고 클러스터가 정상인지 확인한 후 키 버전을 폐기합니다.
심각한 이벤트에 대한 대응으로 키를 순환하는 경우가 아니라면 원래 키 버전을 폐기하기 전에 며칠 기다리는 것이 좋습니다. 자세한 내용은 키 버전 폐기 및 복원을 참고하세요.
이 단계를 완료하면 클러스터의 모든 신규 및 기존 서비스 계정 토큰이 새 키 버전으로 서명됩니다. API 서버는 원래 키 버전이 클러스터 구성에 없기 때문에 원래 키 버전으로 베어러 토큰을 사용하는 요청을 거부합니다.
GKE control plane authority CA 순환
다음 섹션에서는 클러스터가 GKE 컨트롤 플레인 권한에 사용하는 루트 CA를 순환하는 방법을 보여줍니다.
CA의 새 키 버전 만들기
클러스터 루트 CA 키의 새 키 버전을 만듭니다.
gcloud kms keys versions create \ --key=CLUSTER_CA_KEY_NAME \ --keyring=KEYRING_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_ID다음을 바꿉니다.
CLUSTER_CA_KEY_NAME: 클러스터의 클러스터 루트 CA 키 이름입니다.KEYRING_NAME: 키가 저장된 키링의 이름입니다.CONTROL_PLANE_LOCATION: 키링의 Google Cloud 위치입니다. 클러스터 위치와 동일합니다.KEY_PROJECT_ID: 키 프로젝트의 프로젝트 ID
집계 루트 CA 키의 새 키 버전을 만듭니다.
gcloud kms keys versions create \ --key=AGGREGATION_CA_KEY_NAME \ --keyring=KEYRING_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_IDAGGREGATION_CA_KEY_NAME을 클러스터의 집계 루트 CA 키 이름으로 바꿉니다.etcd API 루트 CA 키의 새 키 버전을 만듭니다.
gcloud kms keys versions create \ --key=ETCD_API_CA_KEY_NAME \ --keyring=KEYRING_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_IDETCD_API_CA_KEY_NAME을 클러스터의 etcd API 루트 CA 키 이름으로 바꿉니다.etcd 피어 루트 CA 키의 새 키 버전을 만듭니다.
gcloud kms keys versions create \ --key=ETCD_PEER_CA_KEY_NAME \ --keyring=KEYRING_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_IDETCD_PEER_CA_KEY_NAME을 클러스터의 etcd 피어 루트 CA 키 이름으로 바꿉니다.
새 루트 CA 만들기
새 클러스터 루트 CA 키 버전의 전체 리소스 이름을 가져옵니다.
gcloud kms keys versions list \ --key=CLUSTER_CA_KEY_NAME \ --keyring=KEYRING_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_ID \ --filter="STATE=ENABLED" --sort-by=~ \ --format="value(name)" | sed 1q출력은 다음과 비슷합니다.
projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/CLUSTER_CA_KEY_NAME/cryptoKeyVersions/VERSION이 출력에서
VERSION는 새 키 버전의 번호입니다.클러스터 CA 풀에 새 클러스터 루트 CA를 만듭니다.
gcloud privateca roots create CLUSTER_ROOT_CA_NAME \ --pool=CLUSTER_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --kms-key-version=CLUSTER_CA_KEY_PATH \ --subject="CN=cluster-ca, O=ORGANIZATION" \ --project=KEY_PROJECT_ID다음을 바꿉니다.
CLUSTER_ROOT_CA_NAME: 새 루트 CA의 이름입니다.CLUSTER_CA_POOL_NAME: 클러스터 CA 풀의 이름입니다.CLUSTER_CA_KEY_PATH: 이전 단계의 출력에 있는 새 키 버전의 전체 리소스 이름입니다.ORGANIZATION: 조직 이름
새 집계 루트 CA 키 버전의 전체 리소스 이름을 가져옵니다.
gcloud kms keys versions list \ --key=AGGREGATION_CA_KEY_NAME \ --keyring=KEYRING_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_ID \ --filter="STATE=ENABLED" --sort-by=~ \ --format="value(name)" | sed 1q출력은 다음과 비슷합니다.
projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/AGGREGATION_CA_KEY_NAME/cryptoKeyVersions/VERSION집계 CA 풀에 새 집계 루트 CA를 만듭니다.
gcloud privateca roots create AGGREGATION_ROOT_CA_NAME \ --pool=AGGREGATION_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --kms-key-version=AGGREGATION_CA_KEY_PATH \ --subject="CN=aggregation-ca, O=ORGANIZATION" \ --project=KEY_PROJECT_ID다음을 바꿉니다.
AGGREGATION_ROOT_CA_NAME: 새 집계 루트 CA의 이름입니다.AGGREGATION_CA_POOL_NAME: 집계 CA 풀의 이름입니다.AGGREGATION_CA_KEY_PATH: 이전 단계의 출력에 있는 새 키 버전의 전체 리소스 이름입니다.
새 etcd API 루트 CA 키 버전의 전체 리소스 이름을 가져옵니다.
gcloud kms keys versions list \ --key=ETCD_API_CA_KEY_NAME \ --keyring=KEYRING_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_ID \ --filter="STATE=ENABLED" --sort-by=~ \ --format="value(name)" | sed 1q출력은 다음과 비슷합니다.
projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/ETCD_API_CA_KEY_NAME/cryptoKeyVersions/VERSIONetcd API CA 풀에 새 etcd API 루트 CA를 만듭니다.
gcloud privateca roots create ETCD_API_ROOT_CA_NAME \ --pool=ETCD_API_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --kms-key-version=ETCD_API_CA_KEY_PATH \ --subject="CN=etcd-api-ca, O=ORGANIZATION" \ --project=KEY_PROJECT_ID다음을 바꿉니다.
ETCD_API_ROOT_CA_NAME: 새 etcd API 루트 CA의 이름입니다.ETCD_API_CA_POOL_NAME: etcd API CA 풀의 이름입니다.ETCD_API_CA_KEY_PATH: 이전 단계의 출력에 있는 새 키 버전의 전체 리소스 이름입니다.
새 etcd 피어 루트 CA 키 버전의 전체 리소스 이름을 가져옵니다.
gcloud kms keys versions list \ --key=ETCD_PEER_CA_KEY_NAME \ --keyring=KEYRING_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_ID \ --filter="STATE=ENABLED" --sort-by=~ \ --format="value(name)" | sed 1q출력은 다음과 비슷합니다.
projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/ETCD_PEER_CA_KEY_NAME/cryptoKeyVersions/VERSIONetcd 피어 CA 풀에 새 etcd 피어 루트 CA를 만듭니다.
gcloud privateca roots create ETCD_PEER_ROOT_CA_NAME \ --pool=ETCD_PEER_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --kms-key-version=ETCD_PEER_CA_KEY_PATH \ --subject="CN=etcd-peer-ca, O=ORGANIZATION" \ --project=KEY_PROJECT_ID다음을 바꿉니다.
ETCD_PEER_ROOT_CA_NAME: 새 etcd 피어 루트 CA의 이름입니다.ETCD_PEER_CA_POOL_NAME: etcd 피어 CA 풀의 이름입니다.ETCD_PEER_CA_KEY_PATH: 이전 단계의 출력에 있는 새 키 버전의 전체 리소스 이름입니다.
계속하기 전에 컨트롤 플레인 및 노드 다시 시작 섹션의 안내에 따라 루트 CA 변경사항을 클러스터 신뢰 번들로 전파합니다.
원래 루트 CA를 새 루트 CA로 바꿉니다.
컨트롤 플레인과 노드를 다시 시작한 후 다음 단계를 따르세요.
새 클러스터 루트 CA를 사용 설정합니다.
gcloud privateca roots enable CLUSTER_ROOT_CA_NAME \ --pool=CLUSTER_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_ID새 집계 루트 CA를 사용 설정합니다.
gcloud privateca roots enable AGGREGATION_ROOT_CA_NAME \ --pool=AGGREGATION_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_ID새 etcd API 루트 CA를 사용 설정합니다.
gcloud privateca roots enable ETCD_API_ROOT_CA_NAME \ --pool=ETCD_API_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_ID새 etcd 피어 루트 CA를 사용 설정합니다.
gcloud privateca roots enable ETCD_PEER_ROOT_CA_NAME \ --pool=ETCD_PEER_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_ID원래 클러스터 루트 CA를 사용 중지합니다.
gcloud privateca roots disable ORIGINAL_CLUSTER_ROOT_CA \ --pool=CLUSTER_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_IDORIGINAL_CLUSTER_ROOT_CA을 순환할 원래 클러스터 루트 CA의 이름으로 바꿉니다.원래 집계 루트 CA를 사용 중지합니다.
gcloud privateca roots disable ORIGINAL_AGGREGATION_ROOT_CA \ --pool=AGGREGATION_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_IDORIGINAL_AGGREGATION_ROOT_CA을 순환할 원래 집계 루트 CA의 이름으로 바꿉니다.원본 etcd API 루트 CA를 사용 중지합니다.
gcloud privateca roots disable ORIGINAL_ETCD_API_ROOT_CA \ --pool=ETCD_API_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_IDORIGINAL_ETCD_API_ROOT_CA을 순환할 원래 etcd API 루트 CA의 이름으로 바꿉니다.원래 etcd 피어 루트 CA를 사용 중지합니다.
gcloud privateca roots disable ORIGINAL_ETCD_PEER_ROOT_CA \ --pool=ETCD_PEER_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_IDORIGINAL_ETCD_PEER_ROOT_CA을 순환할 원래 etcd 피어 루트 CA의 이름으로 바꿉니다.이 시점에서 새 루트 CA는 클러스터의 모든 새 인증서를 발급합니다. 각 노드에서
kubelet의 새 인증서를 발급하려면 컨트롤 플레인과 노드를 다시 시작합니다.kubelet인증서는 수명이 길기 때문에 이 단계가 필요합니다.
클러스터가 정상 상태로 유지되는 날이 여러 날 지나면 다음 섹션에 설명된 대로 원래 루트 CA를 삭제할 수 있습니다.
원본 루트 CA 삭제
이 섹션에서는 원래 루트 CA를 삭제하는 방법을 보여줍니다. 이 단계를 따르기 전에 다음을 확인하세요.
- 원래 루트 CA를 새 루트 CA로 바꾼 후 클러스터가 며칠 동안 정상 상태를 유지했습니다.
- 원래 루트 CA에서 발급한 모든 인증서를 새 인증서로 바꿨습니다.
원래 루트 CA를 삭제하려면 다음 단계에 설명된 대로 gcloud privateca roots delete 명령어를 사용합니다. 이러한 명령어에서 --ignore-active-certificates 플래그는 CA에 취소되지 않았거나 만료되지 않은 인증서가 있더라도 유예 기간이 지나면 CA를 삭제합니다.
원본 클러스터 루트 CA를 삭제합니다.
gcloud privateca roots delete ORIGINAL_CLUSTER_ROOT_CA \ --pool=CLUSTER_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_ID \ --ignore-active-certificatesORIGINAL_CLUSTER_ROOT_CA을 순환할 원래 클러스터 루트 CA의 이름으로 바꿉니다.원래 집계 루트 CA를 삭제합니다.
gcloud privateca roots delete ORIGINAL_AGGREGATION_ROOT_CA \ --pool=AGGREGATION_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_ID \ --ignore-active-certificatesORIGINAL_AGGREGATION_ROOT_CA을 순환할 원래 집계 루트 CA의 이름으로 바꿉니다.원래 etcd API 루트 CA를 삭제합니다.
gcloud privateca roots delete ORIGINAL_ETCD_API_ROOT_CA \ --pool=ETCD_API_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_ID \ --ignore-active-certificatesORIGINAL_ETCD_API_ROOT_CA을 순환할 원래 etcd API 루트 CA의 이름으로 바꿉니다.원래 etcd 피어 루트 CA를 삭제합니다.
gcloud privateca roots delete ORIGINAL_ETCD_PEER_ROOT_CA \ --pool=ETCD_PEER_CA_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=KEY_PROJECT_ID \ --ignore-active-certificatesORIGINAL_ETCD_PEER_ROOT_CA을 순환할 원래 etcd 피어 루트 CA의 이름으로 바꿉니다.선택사항: 루트 CA에 대한 변경사항을 클러스터 신뢰 번들로 전파합니다. 자세한 내용은 컨트롤 플레인 및 노드 다시 시작 섹션을 참고하세요. 이 단계를 건너뛰면 다음 컨트롤 플레인 및 노드 버전 업그레이드 중에 원래 루트 CA가 삭제됩니다.
컨트롤 플레인 및 노드 다시 시작
루트 CA 사용 설정, 루트 CA 사용 중지, 인증서 취소와 같은 클러스터의 루트 CA 구성을 변경할 때는 해당 변경사항을 클러스터의 신뢰 번들로 전파해야 합니다. 클러스터의 신뢰 번들 변경사항을 전파하려면 컨트롤 플레인과 (일부 시나리오에서) 노드를 다시 시작합니다.
클러스터 컨트롤 플레인을 이미 사용 중인 버전과 동일한 버전으로 업그레이드합니다.
제어 영역에서 이미 사용 중인 GKE 버전을 찾습니다.
gcloud container clusters describe CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=CLUSTER_PROJECT_ID \ --format="value(currentMasterVersion)"다음을 바꿉니다.
CLUSTER_NAME: GKE 클러스터의 이름입니다.CLUSTER_VERSION: 클러스터가 이미 실행 중인 GKE 버전입니다.CLUSTER_PROJECT_ID: 클러스터 프로젝트의 프로젝트 ID입니다.
컨트롤 플레인 업그레이드:
gcloud container clusters upgrade CLUSTER_NAME \ --master \ --location=CONTROL_PLANE_LOCATION \ --cluster-version=CLUSTER_VERSION \ --project=CLUSTER_PROJECT_ID
Kubernetes CertificateSigningRequests를 사용하여 인증서를 수동으로 생성하는 경우 이러한 인증서를 모두 재발급하고 새 인증서를 API 클라이언트에 제공합니다.
클러스터 루트 CA 순환의 경우에만 각 노드 풀을 이미 사용 중인 동일한 버전으로 업그레이드하여 노드 다시 만들기를 트리거합니다.
노드 풀에서 사용하는 GKE 버전을 찾습니다.
gcloud container node-pools describe NODE_POOL_NAME \ --cluster=CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATION \ --project=CLUSTER_PROJECT_ID \ --format="value(version)"NODE_POOL_NAME을 업그레이드할 노드 풀의 이름으로 바꿉니다.노드 풀을 업그레이드합니다.
gcloud container clusters upgrade CLUSTER_NAME \ --node-pool=NODE_POOL_NAME \ --location=CONTROL_PLANE_LOCATION \ --cluster-version=CLUSTER_VERSION \ --project=CLUSTER_PROJECT_ID
CA 순환 중에 이 섹션의 단계를 수행한 경우 순환의 다음 단계로 진행합니다. 다음 단계는 이 페이지의 다음 섹션 중 하나입니다.