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

Autopilot Standard

---

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

Nesta página, mostramos como configurar o plano de controle do cluster do Google Kubernetes Engine (GKE) com autoridades certificadoras (ACs) e chaves que você gerencia. Estas orientações são destinadas 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. 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. Esta página descreve os recursos opcionais que oferecem mais visibilidade ou controle sobre o plano de controle do GKE.

Você já deve estar familiarizado com os seguintes conceitos:

• Solicitações de assinatura de certificado (CSRs)
• Autoridades certificadoras (ACs)
• etcd
• Arquitetura de cluster do GKE

Componentes de credenciais do plano de controle

Os clusters do GKE usam ACs e chaves específicas para emitir credenciais no cluster, como certificados X.509 ou tokens da conta de serviço. É 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 chaves e ACs gerenciadas pelo Google Cloud.

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

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:

• Gerar suas próprias autoridades certificadoras (CAs) e chaves (página em inglês)
• Criptografar componentes do plano de controle

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

Objetivos

• Criar chaves no Cloud KMS
• Criar ACs no serviço de AC
• Conceder papéis do Identity and Access Management (IAM) ao agente de serviço do GKE
• Criar um cluster do GKE que usa as ACs e chaves
• Verificar se o cluster usa as ACs e chaves

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

• GKE
• Cloud KMS
• CA Service
• Cloud Logging

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.

Antes de começar

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
2. Install the Google Cloud CLI.

3. To initialize the gcloud CLI, run the following command:

   gcloud init

   Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.

4. Make sure that billing is enabled for your Google Cloud project.

5. Enable the Kubernetes Engine, Certificate Authority Service, and Cloud Key Management Service APIs:

   gcloud services enable container.googleapis.com privateca.googleapis.com cloudkms.googleapis.com

6. Install the Google Cloud CLI.

7. To initialize the gcloud CLI, run the following command:

   gcloud init

   Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.

8. Make sure that billing is enabled for your Google Cloud project.

9. Enable the Kubernetes Engine, Certificate Authority Service, and Cloud Key Management Service APIs:

   gcloud services enable container.googleapis.com privateca.googleapis.com cloudkms.googleapis.com

10. Verifique se o ambiente está qualificado para usar os recursos de autoridade do plano de controle do GKE. Para ativar esses recursos, entre em contato com a equipe de vendas do Google Cloud .
11. Para acompanhar de forma confiável a emissão e o uso de credenciais, verifique se os seguintes registros de auditoria de acesso a dados estão ativados:
    • Cloud KMS: DATA_READ
    • Serviço de CA: ADMIN_READ e ADMIN_WRITE

    Para ativar esses tipos de registro, consulte Ativar os registros de auditoria de acesso a dados.

Papéis e permissões necessárias

Para receber as permissões necessárias para executar suas próprias ACs e chaves, peça ao administrador para conceder a você os seguintes papéis do IAM:

• Criar chaves do Cloud KMS: Administrador do Cloud KMS (roles/cloudkms.admin) no seu projeto de chave
• Crie pools de ACs e ACs raiz: Administrador de serviço de AC (roles/privateca.admin) no seu projeto principal
• Criar clusters do GKE: Administrador de cluster do Kubernetes Engine (roles/container.clusterAdmin) no projeto do cluster

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias por meio de papéis personalizados ou de outros papéis predefinidos.

Requisitos

Use o GKE versão 1.31.1-gke.1846000 ou mais recente.

Limitações

Considere as seguintes limitações:

• Só é possível usar chaves do Cloud KMS. Não é possível usar outro provedor do KMS ou outro provedor de criptografia.
• Não é possível usar chaves do Cloud External Key Manager (Cloud EKM).
• Só é possível usar certificados de autoridades de certificação do serviço de CA.

Prepare o ambiente

Nesta seção, você identifica os projetos do Google Cloud que vai usar neste tutorial e cria um keyring no Cloud KMS para armazenar as chaves.

Identificar projetos

Recomendamos o uso de projetos Google Cloud separados da seguinte forma:

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

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

Criar um keyring

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

Observação: não é possível excluir um keyring após a criação. Os keyrings não geram custos adicionais. No entanto, ter muitos keyrings em um projeto pode tornar o gerenciamento de recursos no Cloud KMS mais tedioso.

Execute este comando:

gcloud kms keyrings create KEY_RING_NAME \
    --location=us-central1 \
    --project=KEY_PROJECT_ID

Substitua:

• KEY_RING_NAME: um nome para o keyring.
• KEY_PROJECT_ID: o ID do projeto principal.

Criar chaves

Para cada uma das autoridades de credenciais, como chaves de conta de serviço e ACs, você cria uma chave usando o Cloud KMS. Esta seção mostra como criar as chaves que o GKE usa para assinar e verificar credenciais no cluster. É possível especificar suas próprias propriedades para essas chaves, dependendo das necessidades da 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 outras etapas 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 chaves, poderá usá-lo para armazenar todas as chaves criadas para uso com o cluster.
• O keyring precisa estar no mesmo Google Cloud local do cluster para minimizar a latência.
• As chaves precisam especificar asymmetric-signing como a finalidade da chave.
• Use os algoritmos abaixo com base no tipo de chave:
  • Chaves de assinatura do serviço de conta: um algoritmo PKCS1 de assinatura RSA forte, como rsa-sign-pkcs1-4096-sha256 ou rsa-sign-pkcs1-3072-sha256.
  • Chaves de 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 saber mais sobre chaves de hardware, consulte Cloud HSM.
• Não modifique a duração padrão para a destruição de chaves.
• O GKE não impede a exclusão de chaves do Cloud KMS, incluindo chaves de serviço de AC, que estão em uso pelo cluster. Antes de excluir chaves ou ACs, verifique se os recursos não estão em uso.

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=us-central1\
       --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 dedicada.

2. Crie a chave da AC raiz do cluster:

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

3. Crie a chave de AC raiz do peer do etcd:

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

4. Crie a chave de CA raiz da API etcd:

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

5. Crie a chave de AC raiz de agregação:

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

Criar as ACs

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

1. Crie o pool de ACs do cluster:

   gcloud privateca pools create cluster-ca-pool \
       --location=us-central1 \
       --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. A omissão dessas flags publica certificados em um bucket do Cloud Storage. Para mais detalhes, consulte Ativar a publicação de certificados e CRL de ACs em um pool de ACs.

2. Crie a AC raiz do cluster:

   gcloud privateca roots create cluster-root-ca \
       --pool=cluster-ca-pool \
       --location=us-central1 \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/us-central1/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 do etcd peer:

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

4. Crie a AC raiz do peer do etcd:

   gcloud privateca roots create etcd-peer-root-ca \
       --pool=etcd-peer-ca-pool \
       --location=us-central1 \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/us-central1/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=us-central1 \
       --tier=enterprise \
       --project=KEY_PROJECT_ID \
       --no-publish-crl --no-publish-ca-cert
   

6. Crie a AC raiz da API etcd:

   gcloud privateca roots create etcd-api-root-ca \
       --pool=etcd-api-ca-pool \
       --location=us-central1 \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/us-central1/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 ACs de agregação:

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

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

   gcloud privateca roots create aggregation-root-ca \
       --pool=aggregation-ca-pool \
       --location=us-central1 \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/us-central1/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 ter 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)
• Gerenciador 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 do cluster.

2. Conceda a função 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=us-central1 \
     --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 do cluster.

3. Conceda o papel de administrador de certificados do CA Service nos pools de CA que você criou em Criar as ACs:

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

Configurar ACs e chaves em um novo cluster

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

Depois de criar chaves, pools de AC, AC 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 a flag service-account-signing-keys e para a flag service-account-verification-keys.
• Caminho para cada um dos pools de ACs criados 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ê sim, execute todas as etapas de configuração importantes 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 as chaves e ACs, 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=us-central1 \
       --project=KEY_PROJECT_ID \
       --filter="STATE=ENABLED" --sort-by=~ --format="value(name)" | sed 1q
   

   Substitua KEY_PROJECT_ID pelo ID do projeto de chave.

   O resultado será assim:

   projects/KEY_PROJECT_ID/locations/us-central1/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/us-central1/caPools/cluster-ca-pool
   projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-peer-ca-pool
   projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-api-ca-pool
   projects/KEY_PROJECT_ID/locations/us-central1/caPools/aggregation-ca-pool
   

   Verifique se a saída contém todos os pools de AC que você criou para o GKE.

Crie 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 Autopilot. Para criar clusters no modo padrão, use as mesmas flags com o comando gcloud container clusters create.

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

  gcloud container clusters create-auto example-cluster \
      --location=us-central1 \
      --project=CLUSTER_PROJECT_ID \
      --cluster-version=VERSION \
      --service-account-signing-keys=projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
      --service-account-verification-keys=projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
      --cluster-ca=projects/KEY_PROJECT_ID/locations/us-central1/caPools/cluster-ca-pool \
      --etcd-peer-ca=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-peer-ca-pool \
      --etcd-api-ca=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-api-ca-pool \
      --aggregation-ca=projects/KEY_PROJECT_ID/locations/us-central1/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 ACs e as chaves, bem como a criptografia do disco de inicialização do plano de controle e a criptografia etcd, faça o seguinte:

  1. Realize todas as etapas de configuração de chaves em Criptografar etcd e discos de inicialização 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-auto example-cluster \
         --location=us-central1 \
         --project=CLUSTER_PROJECT_ID \
         --cluster-version=VERSION \
         --service-account-signing-keys=projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
         --service-account-verification-keys=projects/KEY_PROJECT_ID/locations/us-central1/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
         --cluster-ca=projects/KEY_PROJECT_ID/locations/us-central1/caPools/cluster-ca-pool \
         --etcd-peer-ca=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-peer-ca-pool \
         --etcd-api-ca=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-api-ca-pool \
         --aggregation-ca=projects/KEY_PROJECT_ID/locations/us-central1/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 do disco.
     • PATH_TO_ETCD_BACKUP_KEY: o caminho para a chave de criptografia de backup interna do etcd.

  Você também pode usar essas flags ao criar um novo cluster do modo padrão.

Verificar se o cluster usa as chaves e ACs especificadas

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

Usar a geração de registros para verificar chaves e ACs

Para verificar as chaves e as ACs 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 de registros de criação de clusters que incluem chaves e ACs gerenciadas por você.

3. Clique em Executar consulta.

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

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

Usar a CLI gcloud para verificar chaves e ACs

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

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

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

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

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Excluir os projetos

Cuidado: excluir um projeto tem os seguintes efeitos:

• Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Excluir recursos individuais

1. Exclua o cluster:

   gcloud container clusters delete example-cluster \
       --location=us-central1 \
       --project=CLUSTER_PROJECT_ID
   

2. Desative as ACs raiz:

   gcloud privateca roots disable cluster-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/cluster-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots disable etcd-peer-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-peer-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots disable etcd-api-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-api-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots disable aggregation-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/aggregation-ca-pool \
       --project=KEY_PROJECT_ID
   

3. Exclua as ACs raiz:

   gcloud privateca roots delete cluster-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/cluster-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots delete etcd-peer-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-peer-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots delete etcd-api-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/etcd-api-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots delete aggregation-root-ca \
       --location=us-central1 \
       --pool=projects/KEY_PROJECT_ID/locations/us-central1/caPools/aggregation-ca-pool \
       --project=KEY_PROJECT_ID
   

4. Exclua os pools de AC:

   gcloud privateca pools delete cluster-ca-pool --location=us-central1 \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools delete etcd-peer-ca-pool --location=us-central1 \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools delete etcd-api-ca-pool --location=us-central1 \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools delete aggregation-ca-pool --location=us-central1 \
       --project=KEY_PROJECT_ID
   

5. Exclua as chaves:

   gcloud kms keys versions destroy 1 \
       --location=us-central1 \
       --keyring=KEY_RING_NAME \
       --key=sa-signing-key \
       --project=KEY_PROJECT_ID
   
   gcloud kms keys versions destroy 1 \
       --location=us-central1 \
       --keyring=KEY_RING_NAME \
       --key=cluster-ca-key \
       --project=KEY_PROJECT_ID
   
   gcloud kms keys versions destroy 1 \
       --location=us-central1 \
       --keyring=KEY_RING_NAME \
       --key=etcd-peer-ca-key \
       --project=KEY_PROJECT_ID
   
   gcloud kms keys versions destroy 1 \
       --location=us-central1 \
       --keyring=KEY_RING_NAME \
       --key=etcd-api-ca-key \
       --project=KEY_PROJECT_ID
   
   gcloud kms keys versions destroy 1 \
       --location=us-central1 \
       --keyring=KEY_RING_NAME \
       --key=aggregation-ca-key \
       --project=KEY_PROJECT_ID
   

Não é possível excluir chaveiros do Cloud KMS. No entanto, os chaveiros não geram custos adicionais.

A seguir

• Rastrear o uso da identidade desde o momento da emissão
• Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.