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 Google Cloud equipe de conta

.

Neste documento, mostramos como configurar o plano de controle do cluster do Google Kubernetes Engine (GKE) com autoridades certificadoras (CAs) e chaves gerenciadas por você. Esta orientação é destinada 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á deve estar familiarizado com estes conceitos:

• Solicitações de assinatura de certificado (CSRs)
• Autoridades certificadoras (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 CAs no Certificate Authority Service (serviço de CA) e configurar os clusters para usar esses recursos em vez de CAs e chaves gerenciadas pelo Google Cloud.

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

Uso com outros recursos da 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 de certificação (CAs) e chaves (este documento)
• 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.

Objetivos

• Criar chaves no Cloud KMS
• Criar CAs no CA Service
• Conceder papéis do Identity and Access Management (IAM) ao agente de serviço do GKE
• Criar um cluster do GKE que usa 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, use 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

Faça login na sua conta do Google Cloud . Se você começou a usar o Google Cloudagora, crie uma conta para avaliar o desempenho dos nossos produtos em situações reais. Clientes novos também recebem US $300 em créditos para executar, testar e implantar cargas de trabalho.

Instale a CLI do Google Cloud.

Observação:se você já instalou a CLI gcloud, execute o comando 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 CLI gcloud com sua identidade federada.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

Verifique se o faturamento está ativado para o projeto do Google Cloud .

Ative as APIs Kubernetes Engine, Certificate Authority Service e Cloud Key Management Service, se alguma delas ainda não estiver ativada:

Funções necessárias para ativar APIs

Para ativar APIs, você precisa da permissão serviceusage.services.enable. Se você criou o projeto, provavelmente já tem essa permissão pelo papel de Proprietário (roles/owner). Caso contrário, é possível receber essa permissão pelo papel de Administrador do Service Usage (roles/serviceusage.serviceUsageAdmin). Saiba como conceder papéis.

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

Instale a CLI do Google Cloud.

Observação:se você já instalou a CLI gcloud, execute o comando 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 CLI gcloud com sua identidade federada.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

Verifique se o faturamento está ativado para o projeto do Google Cloud .

Ative as APIs Kubernetes Engine, Certificate Authority Service e Cloud Key Management Service, se alguma delas ainda não estiver ativada:

Funções necessárias para ativar APIs

Para ativar APIs, você precisa da permissão serviceusage.services.enable. Se você criou o projeto, provavelmente já tem essa permissão pelo papel de Proprietário (roles/owner). Caso contrário, é possível receber essa permissão pelo papel de Administrador do Service Usage (roles/serviceusage.serviceUsageAdmin). Saiba como conceder papéis.

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 registros, 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 chaves
• Criar pools de ACs e ACs raiz: Administrador de serviço de CA (roles/privateca.admin) no projeto principal
• Crie clusters do GKE: Administrador de clusters 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

Você precisa atender aos seguintes requisitos:

• O cluster precisa executar o GKE versão 1.31.1-gke.1846000 ou posterior.

• Para configurar a criptografia de disco do plano de controle com suas próprias chaves, além de configurar suas próprias CAs, crie o cluster em uma das seguintes regiões:

  • asia-east1
  • asia-northeast1
  • asia-southeast1
  • europe-west1
  • europe-west4
  • us-central1
  • us-central2
  • us-east1
  • us-east4
  • us-east5
  • us-south1
  • us-west1
  • us-west3
  • us-west4
  Observação: separadamente da autoridade do plano de controle do GKE, é possível usar o modo confidencial do Hyperdisk Balanced para os discos de nó. Se você planeja usar o modo confidencial para o Hyperdisk Balanced nos nós, além de criptografar os discos do plano de controle com suas próprias chaves, crie o cluster em uma região que ofereça suporte ao modo confidencial para o Hyperdisk Balanced. Se você criar o cluster em uma região diferente, não poderá usar o modo confidencial para o Hyperdisk Balanced nos seus nós.

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.

Prepare o ambiente

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

Identificar projetos

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

• Projeto principal: 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 chaves 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 tedioso.

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, crie 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. É possível 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.
• Use os seguintes algoritmos com base no tipo de chave:
  • Chaves de assinatura ServiceAccount: 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 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 CA Service, 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 comandos a seguir:

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 AC 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 AC 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 ACs 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. Omitir essas flags publica certificados em um bucket do Cloud Storage. Para mais detalhes, consulte Ativar a publicação de certificados de CA e CRL para CAs em um pool de CAs.

2. Crie a AC 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 ACs de peering 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 AC 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 do etcd API:

   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 ACs 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 que você criou 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)
• Certificate Manager do 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 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 outros papéis 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 seção Configurar CAs e chaves em um novo cluster.

Quando você usa a CLI gcloud para configurar as ACs e chaves, conforme descrito neste documento, a CLI gcloud cria e configura automaticamente um agente de serviço para o CA Service 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 executar essas etapas de configuração manualmente da seguinte maneira para seu projeto principal:

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

   Prévia — acionamento da criação do agente de serviço

   Este recurso está sujeito 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. Para mais informações, consulte as descrições da fase de lançamento.

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

2. Encontre o número do projeto principal:

   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 autoridade certificadora 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 da saída da etapa anterior.

   Esse comando é um loop for que itera pelas chaves da AC raiz, concedendo cada função nessa chave ao agente de serviço 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 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 principais de configuração 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ê vai criar um cluster com diferentes opções especificadas, dependendo dos recursos da GKE control plane authority 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 Standard. Para criar clusters do modo Autopilot, use as mesmas sinalizações com o comando gcloud container clusters create-auto.

• Para configurar apenas as CAs e as 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, além da criptografia do disco de inicialização do plano de controle e do etcd, faça o seguinte:

  1. Siga todas as etapas de configuração de chaves em Criptografar o etcd e os 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 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 novo cluster no modo Standard.

Verificar se o cluster usa as chaves e as CAs especificadas

Nesta seção, mostramos 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 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 que você gerencia.

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 tem os seguintes efeitos:

• 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.

Excluir um projeto do Google Cloud :

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 ACs 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 ACs:

   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 chaveiros não geram custos extras.

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
• Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.