GKE에서 자체 인증 기관 및 키 실행

이 페이지에서는 Google Kubernetes Engine(GKE) 클러스터의 컨트롤 플레인을 사용자가 관리하는 인증 기관(CA)과 키로 구성하는 방법을 설명합니다. 이 가이드는 사용자 인증 정보 발급 및 서명을 제어하기 위해 조직의 규정 준수 또는 정책 요구사항을 충족해야 하는 보안 관리자를 대상으로 합니다.

이 페이지에서는 GKE에서 선택적으로 사용할 수 있는 컨트롤 플레인 기능 중 하나에 대해 설명합니다. 이 기능을 사용하면 컨트롤 플레인 보안 상황을 검증하거나, 사용자가 관리하는 키를 사용해 컨트롤 플레인에서 암호화 및 사용자 인증 정보 서명 작업을 구성할 수 있습니다. 자세한 내용은 GKE control plane authority 정보를 참조하세요.

기본적으로 Google Cloud 는 관리형 컨트롤 플레인에 다양한 보안 조치를 적용합니다. 이 페이지에서는 GKE 컨트롤 플레인에 대해 가시성을 높이거나 제어 권한을 확대할 수 있는 선택적 기능들에 대해 설명합니다.

다음 개념에 익숙해야 합니다.

컨트롤 플레인 사용자 인증 정보 구성요소

GKE 클러스터는 클러스터 내에서 X.509 인증서 또는 ServiceAccount 토큰과 같은 사용자 인증 정보를 발급하기 위해 특정 CA와 키를 사용합니다. Cloud Key Management Service(Cloud KMS)에서 키를 만들고 Certificate Authority Service(CA Service)에서 CA를 만든 후 클러스터가 Google Cloud에서 관리하는 CA와 키 대신 이러한 리소스를 사용하도록 구성할 수 있습니다.

사용자가 만드는 특정 구성요소에 대해 자세히 알아보려면 자체 관리형 CA 및 키를 참조하세요.

다른 GKE control plane authority 기능과의 사용

GKE control plane authority 기능은 다음과 같이 자체 관리형 키와 관련된 기능을 제공합니다.

환경 준비

이 섹션에서는 이 튜토리얼에서 사용할 Google Cloud 프로젝트를 식별하고 키를 보관할 Cloud KMS 키링을 만듭니다.

프로젝트 식별

다음과 같이 별도의 Google Cloud 프로젝트를 사용하는 것이 좋습니다.

  • 키 프로젝트: 모든 키와 CA를 포함합니다.
  • 클러스터 프로젝트: GKE 클러스터를 포함합니다.

선택적으로 키, CA, GKE 클러스터를 동일한 프로젝트에서 사용할 수도 있지만 조직 내에서 암호화 작업을 관리하는 팀과 클러스터 운영을 관리하는 팀을 분리하기 위해 별도의 프로젝트를 사용하는 것이 좋습니다.

키링 만들기

특정 클러스터에 사용할 모든 키를 보관할 키링을 키 프로젝트에 만듭니다. 키링은 GKE 클러스터와 동일한 위치에 만들어야 합니다.

다음 명령어를 실행합니다.

gcloud kms keyrings create KEY_RING_NAME \
    --location=LOCATION \
    --project=KEY_PROJECT_ID

다음을 바꿉니다.

  • KEY_RING_NAME: 키링의 이름입니다.
  • KEY_PROJECT_ID: 키 프로젝트의 프로젝트 ID입니다.
  • LOCATION: 키링을 만들려는 Google Cloud 리전입니다. 이 리전은 GKE 클러스터가 위치한 리전과 동일해야 합니다.

키 만들기

서비스 계정 키 및 CA와 같은 각 사용자 인증 정보 기관에 대해 Cloud KMS를 사용하여 키를 만듭니다. 이 섹션에서는 GKE가 클러스터 내 사용자 인증 정보를 서명하고 확인하는 데 사용하는 키를 만드는 방법을 설명합니다. 조직의 요구사항에 따라 이 키의 속성을 직접 지정할 수 있습니다. 자세한 내용은 키 만들기 페이지와 projects.locations.keyRings.cryptoKeys API 참조를 확인하세요.

Cloud KMS에서 이러한 리소스를 만들 때 다음 사항을 고려하세요.

  • 키 프로젝트에 기존 키링이 있는 경우 해당 키링을 사용하여 클러스터에 사용할 모든 키를 저장할 수 있습니다.
  • 키링은 클러스터와 동일한 Google Cloud 위치에 있어야 지연 시간을 최소화할 수 있습니다.
  • 키는 asymmetric-signing을 키 용도로 지정해야 합니다.
  • 키 유형에 따라 다음 알고리즘을 사용하세요.
    • ServiceAccount 서명 키: rsa-sign-pkcs1-4096-sha256 또는 rsa-sign-pkcs1-3072-sha256과 같은 강력한 RSA PKCS1 서명 알고리즘
    • 인증 기관 키: ec-sign-p256-sha256과 같은 강력한 알고리즘
  • Cloud HSM 하드웨어 키도 지원되지만 대부분의 사용 사례에서는 software 보호 수준으로 충분합니다. 하드웨어 키에 대한 자세한 내용은 Cloud HSM을 참조하세요.
  • 키 삭제의 기본 보존 기간은 변경하지 마세요.
  • GKE는 현재 클러스터에서 사용 중인 CA Service 키를 비롯한 Cloud KMS 키의 삭제를 방지하지 않습니다. 키 또는 CA를 삭제하기 전에 해당 리소스가 더 이상 사용되지 않는지 확인하세요.

키를 만들려면 다음 명령어를 실행하세요.

  1. Kubernetes ServiceAccount 서명 키를 만듭니다. 이 키는 클러스터 생성 시 서비스 계정 확인 키로도 지정됩니다.

    gcloud kms keys create sa-signing-key \
        --keyring=KEY_RING_NAME \
        --location=LOCATION \
        --purpose="asymmetric-signing" \
        --protection-level=hsm \
        --default-algorithm=rsa-sign-pkcs1-4096-sha256 \
        --project=KEY_PROJECT_ID
    

    KEY_PROJECT_ID는 전용 키 프로젝트의 프로젝트 ID로 바꿉니다.

  2. 클러스터 루트 CA 키를 만듭니다.

    gcloud kms keys create cluster-ca-key \
        --keyring=KEY_RING_NAME \
        --location=LOCATION \
        --purpose="asymmetric-signing" \
        --protection-level=hsm \
        --default-algorithm=ec-sign-p256-sha256 \
        --project=KEY_PROJECT_ID
    
  3. etcd 피어 루트 CA 키를 만듭니다.

    gcloud kms keys create etcd-peer-ca-key \
        --keyring=KEY_RING_NAME \
        --location=LOCATION \
        --purpose="asymmetric-signing" \
        --protection-level=hsm \
        --default-algorithm=ec-sign-p256-sha256 \
        --project=KEY_PROJECT_ID
    
  4. etcd API 루트 CA 키를 만듭니다.

    gcloud kms keys create etcd-api-ca-key \
        --keyring=KEY_RING_NAME \
        --location=LOCATION \
        --purpose="asymmetric-signing" \
        --protection-level=hsm \
        --default-algorithm=ec-sign-p256-sha256 \
        --project=KEY_PROJECT_ID
    
  5. 집계 루트 CA 키를 만듭니다.

    gcloud kms keys create aggregation-ca-key \
        --keyring=KEY_RING_NAME \
        --location=LOCATION \
        --purpose="asymmetric-signing" \
        --protection-level=hsm \
        --default-algorithm=ec-sign-p256-sha256 \
        --project=KEY_PROJECT_ID
    

CA 만들기

컨트롤 플레인 기능별로 키를 만든 후 해당 키를 사용하여 CA Service를 통해 CA 풀과 루트 CA를 만듭니다.

  1. 클러스터 CA 풀을 만듭니다.

    gcloud privateca pools create cluster-ca-pool \
        --location=LOCATION \
        --tier=enterprise \
        --project=KEY_PROJECT_ID \
        --no-publish-crl --no-publish-ca-cert
    

    --no-publish-crl 플래그와 --no-publish-ca-cert 플래그는 선택사항입니다. 이러한 플래그를 생략하면 인증서가 Cloud Storage 버킷에 게시됩니다. 자세한 내용은 CA 풀의 CA에 CA 인증서 및 CRL 게시 사용 설정을 참조하세요.

  2. 클러스터 루트 CA를 만듭니다.

    gcloud privateca roots create cluster-root-ca \
        --pool=cluster-ca-pool \
        --location=LOCATION \
        --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/cluster-ca-key/cryptoKeyVersions/1 \
        --subject="CN=cluster-ca, O=ORGANIZATION" \
        --project=KEY_PROJECT_ID \
        --auto-enable
    

    ORGANIZATION을 조직 이름으로 바꿉니다.

  3. etcd 피어 CA 풀을 만듭니다.

    gcloud privateca pools create etcd-peer-ca-pool \
        --location=LOCATION \
        --tier=enterprise \
        --project=KEY_PROJECT_ID \
        --no-publish-crl --no-publish-ca-cert
    
  4. etcd 피어 루트 CA를 만듭니다.

    gcloud privateca roots create etcd-peer-root-ca \
        --pool=etcd-peer-ca-pool \
        --location=LOCATION \
        --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/etcd-peer-ca-key/cryptoKeyVersions/1 \
        --subject="CN=etcd-peer-ca, O=ORGANIZATION" \
        --project=KEY_PROJECT_ID \
        --auto-enable
    
  5. etcd API CA 풀을 만듭니다.

    gcloud privateca pools create etcd-api-ca-pool \
        --location=LOCATION \
        --tier=enterprise \
        --project=KEY_PROJECT_ID \
        --no-publish-crl --no-publish-ca-cert
    
  6. etcd API 루트 CA를 만듭니다.

    gcloud privateca roots create etcd-api-root-ca \
        --pool=etcd-api-ca-pool \
        --location=LOCATION \
        --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/etcd-api-ca-key/cryptoKeyVersions/1 \
        --subject="CN=etcd-api-ca, O=ORGANIZATION" \
        --project=KEY_PROJECT_ID \
        --auto-enable
    
  7. 집계 CA 풀을 만듭니다.

    gcloud privateca pools create aggregation-ca-pool \
        --location=LOCATION \
        --tier=enterprise \
        --project=KEY_PROJECT_ID \
        --no-publish-crl --no-publish-ca-cert
    
  8. 집계 루트 CA를 만듭니다.

    gcloud privateca roots create aggregation-root-ca \
        --pool=aggregation-ca-pool \
        --location=LOCATION \
        --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/aggregation-ca-key/cryptoKeyVersions/1 \
        --subject="CN=aggregation-ca, O=ORGANIZATION" \
        --project=KEY_PROJECT_ID \
        --auto-enable
    

GKE 서비스 에이전트에 IAM 역할 부여

GKE 서비스 에이전트는 Cloud KMS 및 CA Service에서 만든 리소스에 액세스할 수 있어야 합니다. 서비스 에이전트는 이러한 리소스를 사용하여 클러스터 내에서 사용자 인증 정보를 서명하고, 확인하며, 발급합니다. 다음과 같은 사전 정의된 IAM 역할을 사용할 수 있습니다.

GKE 서비스 에이전트에 이러한 역할을 부여하려면 다음 안내를 따르세요.

  1. 클러스터 프로젝트의 프로젝트 번호를 확인합니다.

    gcloud projects describe CLUSTER_PROJECT_ID \
        --format='value(projectNumber)'
    

    CLUSTER_PROJECT_ID를 클러스터 프로젝트의 프로젝트 ID로 바꿉니다.

  2. 키 만들기 단계에서 만든 서비스 계정 서명 키에 대해 Kubernetes Engine KMS 암호화 키 사용자 역할을 부여합니다.

    gcloud kms keys add-iam-policy-binding sa-signing-key \
      --location=LOCATION \
      --keyring=KEY_RING_NAME \
      --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
      --role=roles/container.cloudKmsKeyUser \
      --project=KEY_PROJECT_ID
    

    CLUSTER_PROJECT_NUMBER를 클러스터의 프로젝트의 프로젝트 번호로 바꿉니다.

  3. CA 만들기 단계에서 만든 CA 풀에 대해 CA Service 인증서 관리자 역할을 부여합니다.

    gcloud privateca pools add-iam-policy-binding cluster-ca-pool \
        --location=LOCATION \
        --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
        --role=roles/privateca.certificateManager \
        --project=KEY_PROJECT_ID
    
    gcloud privateca pools add-iam-policy-binding etcd-peer-ca-pool \
        --location=LOCATION \
        --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
        --role=roles/privateca.certificateManager \
        --project=KEY_PROJECT_ID
    
    gcloud privateca pools add-iam-policy-binding etcd-api-ca-pool \
        --location=LOCATION \
        --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
        --role=roles/privateca.certificateManager \
        --project=KEY_PROJECT_ID
    
    gcloud privateca pools add-iam-policy-binding aggregation-ca-pool \
        --location=LOCATION \
        --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
        --role=roles/privateca.certificateManager \
        --project=KEY_PROJECT_ID
    

gcloud CLI를 사용하지 않는 경우 추가 역할 부여

이 섹션에서는 gcloud CLI 대신 Terraform이나 Google Cloud 콘솔과 같은 클라이언트를 사용하여 CA와 키를 구성하려는 경우 수행해야 하는 추가 구성 단계를 설명합니다. gcloud CLI를 사용하는 경우 이 섹션은 건너뛰고 새 클러스터에 CA 및 키 설정 섹션으로 이동합니다.

이 페이지에서 설명한 대로 gcloud CLI를 사용하여 CA와 키를 설정하면 gcloud CLI가 자동으로 CA Service용 서비스 에이전트를 만들고 구성하며 해당 서비스 에이전트에 IAM 역할을 부여합니다. 하지만 Terraform이나 Google Cloud 콘솔과 같은 클라이언트를 사용하여 Google Cloud환경을 구성하는 경우에는 다음과 같이 키 프로젝트에 대한 구성을 수동으로 수행해야 합니다.

  1. CA Service 서비스 에이전트 만들기를 트리거합니다.

    gcloud beta services identity create --service=privateca.googleapis.com \
        --project=KEY_PROJECT_ID
    
  2. 키 프로젝트의 프로젝트 번호를 확인합니다.

    gcloud projects describe KEY_PROJECT_ID \
        --format='value(projectNumber)'
    
  3. 키 만들기 섹션에서 만든 모든 루트 CA 키에 대해 뷰어(roles/viewer) 역할과 Cloud KMS 암호화 키 서명자/확인자(roles/cloudkms.signerVerifier) 역할을 부여합니다.

    for key in cluster-ca-key etcd-peer-ca-key etcd-api-ca-key aggregation-ca-key
    do
    gcloud kms keys add-iam-policy-binding $key \
        --keyring=KEY_RING_NAME \
        --location=LOCATION \
        --role=roles/viewer \
        --member="serviceAccount:service-KEY_PROJECT_NUMBER@gcp-sa-privateca.iam.gserviceaccount.com" \
        --project=KEY_PROJECT_ID
    
    gcloud kms keys add-iam-policy-binding $key \
        --keyring=KEY_RING_NAME \
        --location=LOCATION \
        --role=roles/cloudkms.signerVerifier \
        --member="serviceAccount:service-KEY_PROJECT_NUMBER@gcp-sa-privateca.iam.gserviceaccount.com" \
        --project=KEY_PROJECT_ID
    done
    

    KEY_PROJECT_NUMBER를 이전 단계에서 출력한 키 프로젝트 번호로 바꿉니다.

    이 명령어는 루트 CA 키를 반복하면서 각각의 키에 대해 위 두 개의 역할을 CA Service 서비스 에이전트에 부여하는 for 루프입니다. 루트 CA 키의 이름을 다르게 사용한 경우 각 키에 대해 이 명령어를 수동으로 실행해야 합니다.

새 클러스터에서 CA 및 키 설정

키, CA 풀, 루트 CA를 만들고 GKE 서비스 에이전트에 IAM 역할을 부여한 후 이러한 리소스를 사용하는 새 클러스터를 만듭니다.

클러스터 생성 명령어에서 지정하는 플래그에는 다음 리소스 경로가 값으로 필요합니다.

  • 키 만들기에서 만든 서비스 계정 서명 키를 위한 Cloud KMS의 키 버전 경로. 이 경로는 service-account-signing-keys 플래그와 service-account-verification-keys 플래그 모두에 지정해야 합니다.
  • CA 만들기에서 만든 CA 풀 각각의 경로

새 클러스터에서 직접 만든 키와 CA를 사용하도록 구성하려면 다음 단계를 따르세요.

  1. 사용 설정된 최신 서비스 계정 서명 키 버전의 경로를 찾습니다.

    gcloud kms keys versions list \
        --key=sa-signing-key \
        --keyring=KEY_RING_NAME \
        --location=LOCATION \
        --project=KEY_PROJECT_ID \
        --filter="STATE=ENABLED" --sort-by=~ --format="value(name)" | sed 1q
    

    KEY_PROJECT_ID를 키 프로젝트의 프로젝트 ID로 바꿉니다.

    출력은 다음과 비슷합니다.

    projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1
    
  2. 생성한 각 CA 풀의 경로를 찾습니다.

    gcloud privateca pools list --format="get(name)" \
        --project=KEY_PROJECT_ID
    

    출력은 다음과 비슷합니다.

    projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool
    projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool
    projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool
    projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool
    

    출력에 GKE를 위해 생성한 모든 CA 풀이 포함되어 있는지 확인합니다.

클러스터 만들기

이 섹션에서는 구성하려는 GKE control plane authority 기능에 따라 서로 다른 옵션을 지정하여 클러스터를 만듭니다. 클러스터 생성 중에만 클러스터에 이러한 기능을 구성할 수 있습니다. 다음 명령어는 Standard 모드 클러스터를 만듭니다. Autopilot 모드 클러스터를 만들려면 동일한 플래그를 사용하되, gcloud container clusters create-auto 명령어를 사용하세요.

  • 이 튜토리얼에서 만든 CA와 키만 구성하려는 경우 다음 명령어를 실행하세요.

    gcloud container clusters create example-cluster \
        --location=LOCATION \
        --project=CLUSTER_PROJECT_ID \
        --cluster-version=VERSION \
        --service-account-signing-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
        --service-account-verification-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
        --cluster-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool \
        --etcd-peer-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool \
        --etcd-api-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool \
        --aggregation-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool
    

    다음을 바꿉니다.

    • CLUSTER_PROJECT_ID: 클러스터 프로젝트의 프로젝트 ID입니다.
    • VERSION: 클러스터의 GKE 버전입니다. 1.31.1-gke.1846000 이상이어야 합니다.
  • CA와 키 구성뿐 아니라 컨트롤 플레인 부팅 디스크 암호화 및 etcd 암호화도 구성하려면 다음을 수행하세요.

    1. etcd 및 컨트롤 플레인 부팅 디스크 암호화에 나와 있는 모든 키 구성 단계를 수행합니다.
    2. 클러스터에서 암호화 키 사용의 안내에 따라 각 키의 경로를 찾습니다.
    3. 클러스터를 만듭니다.

      gcloud container clusters create example-cluster \
          --location=LOCATION \
          --project=CLUSTER_PROJECT_ID \
          --cluster-version=VERSION \
          --service-account-signing-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
          --service-account-verification-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
          --cluster-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool \
          --etcd-peer-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool \
          --etcd-api-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool \
          --aggregation-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool \
          --control-plane-disk-encryption-key=PATH_TO_DISK_KEY \
          --gkeops-etcd-backup-encryption-key=PATH_TO_ETCD_BACKUP_KEY
      

      다음을 바꿉니다.

      • CLUSTER_PROJECT_ID: 클러스터 프로젝트의 프로젝트 ID입니다.
      • VERSION: 클러스터의 GKE 버전입니다. 1.31.1-gke.1846000 이상이어야 합니다.
      • PATH_TO_DISK_KEY: 디스크 암호화 키의 경로입니다.
      • PATH_TO_ETCD_BACKUP_KEY: etcd 내부 백업 암호화 키의 경로입니다.

    새 Standard 모드 클러스터를 만들 때도 이러한 플래그를 사용할 수 있습니다.

클러스터가 지정된 키와 CA를 사용하는지 확인

이 섹션에서는 클러스터 생성 시 사용된 키와 CA를 확인하는 방법을 보여줍니다. 이 확인 작업은 Cloud Logging 또는 Google Cloud CLI를 사용하여 수행할 수 있습니다.

Logging을 사용하여 키와 CA 확인

Logging을 사용하여 키와 CA를 확인하려면 다음 단계를 따르세요.

  1. Google Cloud 콘솔에서 로그 탐색기 페이지로 이동합니다.

    로그 탐색기로 이동

  2. 다음 쿼리를 지정합니다.

    resource.type="gke_cluster"
    resource.labels.cluster_name="CLUSTER_NAME"
    resource.labels.location="CLUSTER_LOCATION"
    protoPayload.serviceName="container.googleapis.com"
    protoPayload.methodName=~"google.container.v(1|1alpha1|1beta1).ClusterManager.CreateCluster"
    protoPayload.request.cluster.userManagedKeysConfig:*
    

    protoPayload.request.cluster.userManagedKeysConfig:*는 사용자가 관리하는 키와 CA가 포함된 클러스터 생성 로그의 결과를 필터링합니다.

  3. 쿼리 실행을 클릭합니다.

결과에서 클러스터 생성 로그를 확장합니다. 해당 클러스터에 대해 만든 키 및 CA 경로가 로그에 표시된 경로와 일치하는지 확인합니다. 다음 예시와 유사한 출력을 확인할 수 있습니다.

# lines omitted for clarity
userManagedKeysConfig: {
  aggregationCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool"
  clusterCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool"
  etcdApiCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool"
  etcdPeerCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool"
  serviceAccountSigningKeys: [
    0: "projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1"
  ]
  serviceAccountVerificationKeys: [
    0: "projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1"
  ]
}

gcloud CLI를 사용하여 키와 CA 확인

클러스터가 생성한 CA와 키를 사용하고 있는지 확인하려면 다음 명령어를 실행합니다.

gcloud container clusters describe example-cluster \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID

출력에는 다음 예시와 유사하게 userManagedKeysConfig 필드가 포함되어 있어야 합니다.

# lines omitted for clarity
userManagedKeysConfig:
  sa-signing-key: projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1
  sa-verification-key: projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1
  cluster-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool
  etcd-peer-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool
  etcd-api-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool
  aggregation-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool