Executar suas próprias autoridades de certificação e chaves no GKE

Observação:este documento usa um recurso de disponibilidade geral chamado autoridade do plano de controle do GKE, que está disponível apenas para clientes qualificados do Google Cloud. Para solicitar acesso a esse recurso, entre em contato com a Google Cloud equipe da sua conta

.

Nesta página, mostramos como configurar o plano de controle do cluster do Google Kubernetes Engine (GKE) com autoridades certificadoras (CAs) e chaves gerenciadas por você. Este guia é destinado a administradores de segurança que têm requisitos específicos de compliance ou políticas organizacionais para controlar a emissão e a assinatura de credenciais.

Esta página descreve uma parte de um conjunto de recursos opcionais do plano de controle no GKE que permite realizar tarefas como verificar a postura de segurança do plano de controle ou configurar a criptografia e a assinatura de credenciais no plano de controle usando chaves gerenciadas por você. Para mais detalhes, consulte Sobre a autoridade do plano de controle do GKE.

Por padrão,o Google Cloud aplica várias medidas de segurança ao plano de controle gerenciado. Nesta página, descrevemos os recursos opcionais que oferecem mais visibilidade ou controle sobre o plano de controle do GKE.

Você já precisa conhecer os seguintes conceitos:

• Solicitações de assinatura de certificado (CSRs)
• Autoridades de certificação (CAs)
• etcd
• Arquitetura de cluster do GKE

Componentes de credenciais do plano de controle

Os clusters do GKE usam CAs e chaves específicas para emitir credenciais no cluster, como certificados X.509 ou tokens ServiceAccount. É possível criar chaves no Cloud Key Management Service (Cloud KMS) e ACs no Certificate Authority Service (serviço de AC) e configurar seus clusters para usar esses recursos em vez de ACs e chaves gerenciadas por Google Cloud.

Para saber mais sobre os componentes específicos que você cria, consulte CAs e chaves autogerenciadas.

Uso com outros recursos de autoridade do plano de controle do GKE

A autoridade do plano de controle do GKE oferece os seguintes recursos relacionados a chaves autogerenciadas:

• Executar suas próprias autoridades certificadoras (CAs) e chaves (esta página)
• Criptografar componentes do plano de controle

Observação: só é possível ativar esses recursos ao criar um cluster do GKE. Não é possível atualizar clusters atuais para usar esses recursos. Para usar os dois recursos no mesmo cluster, siga todos os procedimentos de configuração de chave e CA nos dois guias e execute o comando de criação de cluster que ativa os dois conjuntos de recursos, conforme descrito na seção Criar um cluster.

Prepare o ambiente

Nesta seção, você vai identificar os projetos Google Cloud que serão usados neste tutorial e criar um keyring no Cloud KMS para armazenar as chaves.

Identificar projetos

Recomendamos que você use projetos Google Cloud separados da seguinte maneira:

• Projeto de chave: contém todas as chaves e CAs.
• Projeto de cluster: contém seus clusters do GKE.

Você pode usar o mesmo projeto para chaves, CAs e clusters do GKE, mas recomendamos que use projetos separados para que as equipes que gerenciam operações criptográficas na sua organização sejam separadas das equipes que gerenciam operações de cluster.

Criar um keyring

Crie um keyring no projeto de chave para armazenar todas as chaves de um cluster específico. Crie o keyring no mesmo local do cluster do GKE.

Observação: não é possível excluir um keyring depois de criado. Os keyrings não geram custos adicionais. No entanto, ter muitos keyrings em um projeto pode tornar o gerenciamento dos recursos no Cloud KMS mais complicado.

Execute este comando:

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

Substitua:

• KEY_RING_NAME: um nome para o keyring.
• KEY_PROJECT_ID: o ID do projeto da chave.
• LOCATION: a região Google Cloud em que você quer criar o keyring. Precisa ser a mesma região em que o cluster do GKE está localizado.

Criar chaves

Para cada uma das autoridades de credenciais, como chaves de conta de serviço e CAs, você cria uma chave usando o Cloud KMS. Nesta seção, mostramos como criar as chaves que o GKE usa para assinar e verificar credenciais no cluster. Você pode especificar suas próprias propriedades para essas chaves, dependendo das necessidades da sua organização. Para mais detalhes, consulte a página Criar uma chave e a referência da API projects.locations.keyRings.cryptoKeys.

Atenção: não ative a rotação automática de chaves com o Cloud KMS. A rotação das chaves de criptografia exige etapas adicionais para garantir que os recursos do plano de controle sejam criptografados novamente com novas versões de chave antes que as versões originais sejam destruídas.

Considere o seguinte ao criar esses recursos no Cloud KMS:

• Se você tiver um keyring no projeto de chave, use-o para armazenar todas as chaves criadas para uso com o cluster.
• O keyring precisa estar no mesmo local Google Cloud do cluster para minimizar a latência.
• As chaves precisam especificar asymmetric-signing como a finalidade da chave.
• Use os seguintes algoritmos com base no tipo de chave:
  • Chaves de assinatura de conta de serviço: um algoritmo PKCS1 de assinatura RSA forte, como rsa-sign-pkcs1-4096-sha256 ou rsa-sign-pkcs1-3072-sha256.
  • Chaves da autoridade certificadora: um algoritmo forte, como ec-sign-p256-sha256.
• As chaves de hardware do Cloud HSM são compatíveis, mas o nível de proteção software é suficiente para a maioria dos casos de uso. Para mais detalhes sobre chaves de hardware, consulte Cloud HSM.
• Não modifique a duração padrão para destruição de chaves.
• O GKE não impede que você exclua chaves do Cloud KMS, incluindo chaves do serviço de CA, que estão em uso pelo cluster. Antes de excluir chaves ou CAs, verifique se os recursos não estão sendo usados.

Para criar as chaves, execute os seguintes comandos:

1. Crie a chave de assinatura da conta de serviço do Kubernetes, que também é especificada como a chave de verificação da conta de serviço durante a criação do cluster:

   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
   

   Substitua KEY_PROJECT_ID pelo ID do projeto de chave dedicado.

2. Crie a chave da CA raiz do cluster:

   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. Crie a chave da CA raiz do peer etcd:

   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. Crie a chave da CA raiz da API etcd:

   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. Crie a chave da CA raiz de agregação:

   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
   

Criar as CAs

Depois de criar as chaves para cada uma das funções do plano de controle, use cada chave para criar os pools de CA e as CAs raiz correspondentes usando o serviço de CA:

1. Crie o pool de CAs do cluster:

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

   As flags --no-publish-crl e --no-publish-ca-cert são opcionais. Se você omitir essas flags, os certificados serão publicados em um bucket do Cloud Storage. Para mais detalhes, consulte Ativar a publicação de certificados de CA e CRLs para CAs em um pool de CAs.

2. Crie a CA raiz do cluster:

   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
   

   Substitua ORGANIZATION pelo nome da sua organização.

3. Crie o pool de CAs de peer do etcd:

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

4. Crie a CA raiz do peer etcd:

   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. Crie o pool de ACs da API etcd:

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

6. Crie a CA raiz da API etcd:

   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. Crie o pool de CAs de agregação:

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

8. Crie a CA raiz de agregação:

   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
   

Conceder papéis do IAM ao agente de serviço do GKE

O agente de serviço do GKE precisa de acesso aos recursos criados no Cloud KMS e no serviço de CA. O agente de serviço usa esses recursos para assinar, verificar e emitir credenciais no cluster. Você pode usar os seguintes papéis predefinidos do IAM:

• Usuário de chaves criptográficas do KMS do Kubernetes Engine (roles/container.cloudKmsKeyUser)
• Gerente de certificado de serviço de CA (roles/privateca.certificateManager)

Para conceder esses papéis ao agente de serviço do GKE, faça o seguinte:

1. Encontre o número do projeto do cluster:

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

   Substitua CLUSTER_PROJECT_ID pelo ID do projeto de cluster.

2. Conceda o papel de usuário da chave criptográfica do KMS do Kubernetes Engine à chave de assinatura da conta de serviço que você criou em Criar chaves:

   gcloud kms keys add-iam-policy-binding sa-signing-key \
     --location=LOCATION \
     --keyring=KEY_RING_NAME \
     --member="serviceAccount:[e-mail]" \
     --role=roles/container.cloudKmsKeyUser \
     --project=KEY_PROJECT_ID
   

   Substitua CLUSTER_PROJECT_NUMBER pelo número do projeto de cluster.

3. Conceda o papel de gerente de certificados do serviço de AC nos pools de ACs que você criou em Criar as ACs:

   gcloud privateca pools add-iam-policy-binding cluster-ca-pool \
       --location=LOCATION \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools add-iam-policy-binding etcd-peer-ca-pool \
       --location=LOCATION \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools add-iam-policy-binding etcd-api-ca-pool \
       --location=LOCATION \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools add-iam-policy-binding aggregation-ca-pool \
       --location=LOCATION \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   

Conceder papéis adicionais quando não estiver usando a CLI gcloud

Esta seção descreve etapas de configuração adicionais que você precisa realizar se planeja configurar suas CAs e chaves usando um cliente como o Terraform ou o console Google Cloud em vez de usar a CLI gcloud. Se você usar a CLI gcloud, pule esta seção e acesse a Configurar ACs e chaves em um novo cluster.

Quando você usa a CLI gcloud para configurar suas CAs e chaves, conforme descrito nesta página, a CLI gcloud cria e configura automaticamente um agente de serviço para o serviço de CA e concede papéis do IAM a ele. No entanto, se você usar um cliente como o Terraform ou o console Google Cloud para configurar seu ambiente Google Cloud, será necessário realizar as etapas de configuração manualmente da seguinte forma para seu projeto principal:

1. Acione a criação do agente de serviço do serviço de AC.

   Pré-lançamento — triggering service agent creation

   Este recurso está sujeitos aos "Termos das Soluções Pré-GA" na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis no estado em que se encontram e podem ter suporte limitado. Você encontra mais detalhes nas descrições das fases de lançamento.

   gcloud beta services identity create --service=privateca.googleapis.com \
       --project=KEY_PROJECT_ID
   

2. Encontre o número do projeto da sua chave:

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

3. Conceda o papel Leitor (roles/viewer) e o papel Signatário/verificador de CryptoKey do Cloud KMS (roles/cloudkms.signerVerifier) em todas as chaves da CA raiz que você criou na seção Criar chaves:

   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:[e-mail]" \
       --project=KEY_PROJECT_ID
   
   gcloud kms keys add-iam-policy-binding $key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --role=roles/cloudkms.signerVerifier \
       --member="serviceAccount:[e-mail]" \
       --project=KEY_PROJECT_ID
   done
   

   Substitua KEY_PROJECT_NUMBER pelo número do projeto principal na saída da etapa anterior.

   Esse comando é um loop for que itera pelas chaves da CA raiz, concedendo cada função nessa chave ao agente de serviços do CA Service. Se você usou nomes diferentes para as chaves da CA raiz, execute esses comandos manualmente para cada chave.

Configurar CAs e chaves em um novo cluster

Aviso: excluir chaves ou CAs em uso pelo cluster pode levar a clusters irrecuperáveis. Antes de excluir chaves ou CAs, verifique se o cluster não usa mais os recursos.

Depois de criar chaves, pools de CA, CAs raiz e conceder papéis do IAM ao agente de serviço do GKE, crie um cluster que use esses recursos.

As flags especificadas no comando de criação do cluster exigem os seguintes caminhos de recursos como valores:

• Caminho para uma versão de chave no Cloud KMS para a chave de assinatura da conta de serviço que você criou em Criar chaves. Especifique esse caminho para as flags service-account-signing-keys e service-account-verification-keys.
• Caminho para cada um dos pools de ACs que você criou em Criar as ACs.

Observação: antes de realizar estas etapas, decida se você também quer criptografar os discos de inicialização do plano de controle e os discos etcd com chaves gerenciadas por você. Se você fizer isso, execute todas as etapas de configuração de chaves em Criptografar discos de inicialização do etcd e do plano de controle e especifique as flags opcionais descritas no comando de criação de cluster nesta seção.

Para configurar um novo cluster para usar suas chaves e CAs, siga estas etapas:

1. Encontre o caminho para a versão mais recente da chave de assinatura da conta de serviço ativada:

   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
   

   Substitua KEY_PROJECT_ID pelo ID do projeto da chave.

   O resultado será assim:

   projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1
   

2. Encontre os caminhos para cada um dos pools de ACs que você criou:

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

   O resultado será assim:

   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
   

   Verifique se a saída contém todos os pools de ACs criados para o GKE.

Criar um cluster

Nesta seção, você cria um cluster com diferentes opções especificadas dependendo dos recursos de autoridade do plano de controle do GKE que você quer configurar. Só é possível configurar esses recursos em um cluster durante a criação dele. Os comandos a seguir criam clusters do modo Standard. Para criar clusters no modo Autopilot, use as mesmas flags com o comando gcloud container clusters create-auto.

• Para configurar apenas as CAs e chaves criadas neste tutorial, execute o seguinte comando:

  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
  

  Substitua:

  • CLUSTER_PROJECT_ID: o ID do projeto do cluster.
  • VERSION: a versão do GKE do cluster. Precisa ser 1.31.1-gke.1846000 ou mais recente.

• Para configurar as CAs e chaves, bem como a criptografia do disco de inicialização do plano de controle e a criptografia do etcd, faça o seguinte:

  1. Siga todas as etapas de configuração de chave em Criptografar discos de inicialização do etcd e do plano de controle.
  2. Encontre os caminhos para cada uma das chaves usando as instruções em Usar chaves de criptografia em um cluster.

  3. Crie um cluster:

     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
     

     Substitua:

     • CLUSTER_PROJECT_ID: o ID do projeto do cluster.
     • VERSION: a versão do GKE do cluster. Precisa ser 1.31.1-gke.1846000 ou mais recente.
     • PATH_TO_DISK_KEY: o caminho para a chave de criptografia de disco.
     • PATH_TO_ETCD_BACKUP_KEY: o caminho para a chave de criptografia de backup interno do etcd.

  Você também pode usar essas flags ao criar um cluster no modo Standard.

Verificar se o cluster usa as chaves e as autoridades de certificação especificadas

Esta seção mostra como verificar as chaves e as CAs usadas durante a criação do cluster. É possível fazer essa verificação usando o Cloud Logging ou a Google Cloud CLI.

Usar o Cloud Logging para verificar chaves e CAs

Para verificar as chaves e as CAs usando o Logging, faça o seguinte:

1. No console do Google Cloud , acesse a página Análise de registros:

   Acessar o Explorador de registros

2. Especifique a seguinte consulta:

   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:* filtra os resultados para registros de criação de cluster que incluem chaves e CAs gerenciadas por você.

3. Clique em Executar consulta.

Nos resultados, expanda o registro de criação do cluster. Verifique se os caminhos para chaves e CAs são os mesmos que você criou para esse cluster, como no exemplo a seguir:

# 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"
  ]
}

Usar a CLI gcloud para verificar chaves e CAs

Para verificar se o cluster usa as CAs e as chaves que você criou, execute o seguinte comando:

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

A saída precisa incluir o campo userManagedKeysConfig, como no exemplo a seguir:

# 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