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 está disponível apenas para clientes qualificados do Google Cloud. Para solicitar acesso a esse recurso, entre em contato com a equipe da sua conta do Google Cloud .

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 controle sobre a emissão e 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 (CA Service) 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 novo 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.

Objetivos

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

Custos

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

• GKE
• Cloud KMS
• CA Service
• Cloud Logging

Para gerar uma estimativa de custo baseada na sua projeção de uso, utilize a calculadora de preços.

Novos usuários do Google Cloud podem estar qualificados para um teste sem custo financeiro.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Para mais informações, consulte Limpeza.

Antes de começar

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.

Install the Google Cloud CLI.

Observação: se você já instalou a gcloud CLI, execute gcloud components update para verificar se tem a versão mais recente.

Ao usar um provedor de identidade (IdP) externo, primeiro faça login na gcloud CLI com sua identidade federada.

Para inicializar a gcloud CLI, execute o seguinte comando:

gcloud init

Verify that billing is enabled for your Google Cloud project.

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

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

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

Install the Google Cloud CLI.

Observação: se você já instalou a gcloud CLI, execute gcloud components update para verificar se tem a versão mais recente.

Ao usar um provedor de identidade (IdP) externo, primeiro faça login na gcloud CLI com sua identidade federada.

Para inicializar a gcloud CLI, execute o seguinte comando:

gcloud init

Verify that billing is enabled for your Google Cloud project.

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

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

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

1. 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 sua equipe de vendas do Google Cloud .
2. Para rastrear de maneira confiável a emissão e o uso de credenciais, verifique se os seguintes registros de auditoria de acesso a dados estão ativados:
   • API Cloud Key Management Service (KMS): DATA_READ
   • Certificate Authority Service: ADMIN_READ

   Para ativar esses tipos de registro, consulte Ativar 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 CAs e chaves, peça ao administrador que conceda a você os seguintes papéis do IAM:

• Crie chaves do Cloud KMS: Administrador do Cloud KMS (roles/cloudkms.admin) no projeto de chave
• Criar pools de CAs e CAs raiz: Administrador de serviço de CA (roles/privateca.admin) no seu projeto principal
• Crie 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 usando papéis personalizados ou outros papéis predefinidos.

Requisitos

Use o GKE versão 1.31.1-gke.1846000 ou posterior.

Limitações

Considere as seguintes limitações:

• Só é possível usar chaves do Cloud KMS. Não é possível usar outro provedor de KMS ou de criptografia.
• As chaves do Cloud External Key Manager (Cloud EKM) não são compatíveis.
• Só é possível usar CAs do serviço de CA.

• As regiões e zonas em que você pode usar a autoridade do plano de controle do GKE dependem de você querer usar recursos específicos, da seguinte forma:

  • Para criptografar os discos de inicialização do plano de controle com uma chave de criptografia gerenciada pelo cliente, o cluster precisa estar em uma das seguintes regiões:
    • asia-east1
    • asia-northeast1
    • asia-southeast1
    • europe-west1
    • europe-west4
    • us-central1
    • us-east1
    • us-east4
    • us-east5
    • us-south1
    • us-west1
    • us-west3
    • us-west4
  • Para usar os nós confidenciais do GKE com a autoridade do plano de controle do GKE, o cluster precisa estar em uma região que ofereça suporte ao modo confidencial para o Hyperdisk equilibrado.

  Se você não usa esses recursos, pode usar a autoridade do plano de controle do GKE em qualquer local Google Cloud .

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 criá-lo. 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 Google Cloud local do cluster para minimizar a latência.
• As chaves precisam especificar asymmetric-signing como a finalidade.
• 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 dedicada.

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 CA Service:

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 CA Service. 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 do 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

Nesta seção, descrevemos 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 essas 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á sujeito aos "Termos da Oferta 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 assistência limitada. Para mais informações, consulte as 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 os papéis Leitor (roles/viewer) e Signatário/verificador de CryptoKey do Cloud KMS (roles/cloudkms.signerVerifier) em todas as chaves da AC 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 que estão 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 criada 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á o seguinte:

   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á o seguinte:

   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 no modo padrão. 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 CAs 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 a Análise 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

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: a exclusão de um projeto pode gerar os efeitos a seguir.

• Tudo no projeto é excluído. Se você tiver usado um projeto atual para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos nele.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um ID 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 explorar várias arquiteturas, tutoriais e guias de início rápido, a reutilização de projetos pode evitar que você exceda limites da cota.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Excluir recursos individuais

1. Exclua o cluster:

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

2. Desative as CAs raiz:

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

3. Exclua as CAs raiz:

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

4. Exclua os pools de CA:

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

5. Exclua as chaves:

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

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

A seguir

• Rastrear o uso da identidade desde o momento da emissão
• Alternar as CAs e as chaves de assinatura da conta de serviço (prévia)
• Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.