Esta página foi traduzida pela API Cloud Translation.

Alternar CAs e chaves do plano de controle gerenciado pelo cliente

Standard

Nesta página, mostramos aos administradores de cluster e engenheiros de segurança como alternar as autoridades de certificação (CAs) e as chaves de assinatura da conta de serviço que você configurou para a autoridade do plano de controle do GKE.

Você precisa conhecer os seguintes conceitos:

Planejar rotações de credenciais

Nesta página, mostramos como alternar os seguintes componentes de credenciais no seu plano de controle:

A CA raiz do cluster, a CA raiz de agregação, a CA raiz da API etcd e a CA raiz do peer etcd.
As chaves de assinatura e verificação da conta de serviço do Kubernetes.

Também é possível fazer a rotação das chaves de criptografia gerenciadas pelo cliente usadas para criptografar os discos de inicialização do plano de controle, os discos do etcd e o backup interno do etcd que o Google Cloud usa para recuperação de desastres. Para mais informações, consulte Fazer rotação das chaves de criptografia do disco de inicialização do etcd e do plano de controle.

Faça a rotação das suas credenciais para evitar o vencimento da CA, reduzir os riscos de comprometimento da versão da chave e como parte das práticas de segurança da sua organização. Para planejar a frequência com que você gira recursos específicos da autoridade do plano de controle do GKE, considere o seguinte:

Por padrão, os certificados do GKE assinados pelas CAs raiz no Certificate Authority Service (CA Service) expiram um ano após a data de criação.
As chaves no Cloud Key Management Service (Cloud KMS) não expiram. Faça uma rotação manual de chaves apenas se sua organização tiver requisitos para isso. Para minimizar as interrupções nas cargas de trabalho em execução, não configure a rotação automática de chaves para elas.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Ativar a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. Se você instalou a gcloud CLI anteriormente, instale a versão mais recente executando gcloud components update.
Observação: em instalações prévias da gcloud CLI, defina a propriedade compute/region. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, é possível evitar erros na gcloud CLI como: One of [--zone, --region] must be supplied: Please specify location. Talvez seja necessário especificar o local em determinados comandos se o local do cluster for diferente do padrão definido.

Ter um cluster que usa CAs autogerenciadas e chaves de conta de serviço
Identifique os IDs dos seguintes projetos do Google Cloud :
- Projeto de chave: o projeto que contém os recursos do Cloud KMS e do CA Service.
- Projeto de cluster: o projeto que contém seu cluster do GKE.
Para realizar as tarefas de validação nesta página, 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 fazer a rotação das CAs e chaves gerenciadas pelo cliente, peça ao administrador para conceder a você os seguintes papéis do IAM:

Gerenciar chaves ou versões de chaves: Administrador do Cloud KMS (roles/cloudkms.admin) no projeto de chave
Gerenciar CAs raiz: Administrador do serviço de CA (roles/privateca.admin) no projeto principal
Configure os clusters para usar novas credenciais: 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.

Limitações

As chaves assimétricas do Cloud KMS usadas para assinatura e verificação de contas de serviço não são compatíveis com a rotação automática de chaves.

Fazer a rotação das chaves de assinatura e verificação da conta de serviço

Ao configurar a autoridade do plano de controle do GKE, você adiciona uma chave de assinatura de conta de serviço e chaves de verificação de conta de serviço ao cluster. O GKE usa essas chaves para assinar e validar tokens do portador para contas de serviço do Kubernetes. Durante uma rotação, adicione a nova chave à lista de chaves de verificação da conta de serviço, aguarde a propagação das mudanças e substitua a chave de assinatura da conta de serviço pela nova.

Para alternar as chaves da conta de serviço, siga estas etapas:

Encontre o nome completo do recurso da versão original da chave de assinatura da conta de serviço:
```
gcloud container clusters describe CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --format="value(userManagedKeysConfig.serviceAccountSigningKeys)"
```
Substitua:
- CLUSTER_NAME: o nome do cluster.
- CONTROL_PLANE_LOCATION: O local do cluster.
- CLUSTER_PROJECT_ID: o ID do projeto do cluster.
O resultado será assim:
```
projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/SIGNING_KEY_NAME/cryptoKeyVersions/ORIGINAL_SIGNING_KEY_VERSION
```
Nesta saída, SIGNING_KEY_NAME é o nome da chave e ORIGINAL_SIGNING_KEY_VERSION é o número da versão original da chave de assinatura.
Crie uma nova versão da chave de assinatura da conta de serviço:
```
gcloud kms keys versions create \
    --key=SIGNING_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID
```
Substitua:
- SIGNING_KEY_NAME: o nome da chave de assinatura da conta de serviço.
- KEYRING_NAME: o nome do keyring que contém a chave.
- CONTROL_PLANE_LOCATION: a Google Cloud localização do keyring.
- KEY_PROJECT_ID: o ID do projeto do projeto da chave.

Encontre o nome completo do recurso da nova versão da chave:

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

O resultado será assim:

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/SIGNING_KEY_NAME/cryptoKeyVersions/NEW_SIGNING_KEY_VERSION

Nesta saída, SIGNING_KEY_NAME é o nome da chave e NEW_SIGNING_KEY_VERSION é o número da nova versão da chave de assinatura.

Adicione a nova versão da chave ao conjunto de chaves de verificação da conta de serviço do cluster:
```
gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --service-account-verification-keys=ORIGINAL_KEY_VERSION_PATH,NEW_KEY_VERSION_PATH
```
Substitua:
- ORIGINAL_KEY_VERSION_PATH: o nome completo do recurso da versão original da chave de assinatura da saída da primeira etapa desta seção. Por exemplo, projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/1.
- NEW_KEY_VERSION_PATH: o nome completo do recurso da nova versão da chave de assinatura na saída da etapa anterior. Por exemplo, projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/2.
Depois que a operação de atualização do cluster for concluída, pode levar até 10 minutos para que o novo caminho da versão da chave seja propagado para o servidor da API Kubernetes e todos os endpoints da API GKE.

Para confirmar que o novo caminho da versão da chave foi totalmente propagado, faça o seguinte:

Receba o componente público das chaves de assinatura do cluster da API GKE como um conjunto de chaves da Web JSON (JWKS):

curl https://container.googleapis.com/v1/projects/CLUSTER_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/jwks

O resultado será assim:

{
  "keys": [
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY1_ID",
      "n": "KEY1_MODULUS",
      "e": "KEY1_EXPONENT"
    },
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY2_ID",
      "n": "KEY2_MODULUS",
      "e": "KEY2_EXPONENT"
    }
  ]
}

Essa saída precisa ter duas entradas de chave, o que indica que as duas versões da chave estão disponíveis na API GKE. Se você só vir uma entrada de chave, aguarde 10 minutos e tente novamente o comando.

Conecte-se ao cluster para executar comandos kubectl:

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Receba o componente público das chaves de assinatura do cluster do servidor da API Kubernetes como um JWKS:

kubectl get --raw /openid/v1/jwks | jq

O resultado será assim:

{
  "keys": [
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY1_ID",
      "n": "KEY1_MODULUS",
      "e": "KEY1_EXPONENT"
    },
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY2_ID",
      "n": "KEY2_MODULUS",
      "e": "KEY2_EXPONENT"
    }
  ]
}

Essa saída precisa ter duas entradas principais, o que indica que ambas as versões principais estão disponíveis no servidor da API Kubernetes. Se você só vir uma entrada de chave, aguarde 10 minutos e tente novamente o comando.

Atualize o cluster para usar a nova versão da chave como a chave de assinatura da conta de serviço:

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --service-account-signing-key=NEW_KEY_VERSION_PATH

Verifique se os novos tokens de conta de serviço usam a nova versão da chave:

Crie uma ServiceAccount:

kubectl create serviceaccount test-sa-1

Crie um token para a ServiceAccount:
```
kubectl create token test-sa-1
```

Extraia um resumo assinado recentemente do Logging:

export SIGNED_DIGEST=$(gcloud logging read \
    'resource.type="gke_cluster" '\
    'AND resource.labels.cluster_name="' CLUSTER_NAME '" '\
    'AND protoPayload.methodName="google.cloud.gkeauth.v1.Auth.SignServiceAccountJWT" '\
    'AND protoPayload.metadata.subject="system:serviceaccount:default:test-sa-1"' \
    --freshness=1h \
    --bucket=_Required \
    --location=global \
    --view=_AllLogs \
    --order=DESC \
    --limit=1 \
    --format="value(protoPayload.metadata.toBeSignedDigest)")

Valide se a nova versão da chave de assinatura está em uso:

  gcloud logging read \
      'resource.type="cloudkms_cryptokeyversion" '\
      'AND protoPayload.methodName="AsymmetricSign" '\
      'AND protoPayload.request.digest.sha256="'${SIGNED_DIGEST}'"' \
      --freshness=1h \
      --bucket=_Default \
      --location=global \
      --view=_AllLogs \
      --order=DESC \
      --limit=1 \
      --format="value(protoPayload.resourceName)"
  ```
The output is the resource path of the new signing key version.

Aguarde a expiração de todos os tokens no cluster que usa a versão da chave de assinatura da conta de serviço original. Por padrão, a vida útil do token é de uma hora, com um máximo configurável de 24 horas. Para verificar o tempo de vida do token configurado no cluster, execute o seguinte comando:
```
kubectl get pods -A -o json | jq -r '.items[]?.spec?.volumes[]?.projected?.sources[]?.serviceAccountToken?.expirationSeconds | select(. != null)' | sort -nr | head -n 1
```
Observação: se você armazenar tokens de ServiceAccount em Secrets, recrie os Secrets para que o Kubernetes gere novos tokens assinados pela nova versão da chave.
Aguarde o tempo de vida do token configurado na saída da etapa anterior passar. Depois desse período, todos os tokens vinculados no cluster vão usar a nova versão da chave de assinatura da conta de serviço.

Remova a versão original da chave da lista de chaves de verificação do cluster:

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --service-account-verification-keys=NEW_KEY_VERSION_PATH

Opcional: desative a versão original da chave. Depois de verificar se a versão de chave original não está sendo usada e se o cluster está íntegro, destrua a versão de chave.

A menos que você esteja fazendo a rotação das chaves em resposta a um evento crítico, recomendamos que aguarde alguns dias antes de destruir a versão original da chave. Para mais informações, consulte Destruir e restaurar versões de chave.

Depois de concluir essas etapas, todos os tokens de conta de serviço novos e atuais no cluster serão assinados pela nova versão da chave. O servidor da API rejeita qualquer solicitação que use um token de portador com a versão original da chave, porque a versão original não existe na configuração do cluster.

Fazer a rotação das CAs da autoridade do plano de controle do GKE

As seções a seguir mostram como fazer a rotação das CAs raiz que o cluster usa para a autoridade do plano de controle do GKE.

Criar novas versões de chave para as CAs

Crie uma nova versão da chave da CA raiz do cluster:
```
gcloud kms keys versions create \
    --key=CLUSTER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID
```
Substitua:
- CLUSTER_CA_KEY_NAME: o nome da chave da AC raiz do cluster.
- KEYRING_NAME: o nome do keyring que contém a chave.
- CONTROL_PLANE_LOCATION: a Google Cloud localização do keyring. É o mesmo local do cluster.
- KEY_PROJECT_ID: o ID do projeto do projeto da chave.

Crie uma nova versão da chave da CA raiz de agregação:

gcloud kms keys versions create \
    --key=AGGREGATION_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Substitua AGGREGATION_CA_KEY_NAME pelo nome da chave da CA raiz de agregação do cluster.

Crie uma nova versão da chave para a chave da CA raiz da API etcd:

gcloud kms keys versions create \
    --key=ETCD_API_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Substitua ETCD_API_CA_KEY_NAME pelo nome da chave da CA raiz da API etcd para o cluster.

Crie uma versão de chave para a chave da CA raiz do peer etcd:

gcloud kms keys versions create \
    --key=ETCD_PEER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Substitua ETCD_PEER_CA_KEY_NAME pelo nome da chave da CA raiz do peer etcd para o cluster.

Criar novas CAs raiz

Receba o nome completo do recurso da nova versão da chave da CA raiz do cluster:

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

O resultado será assim:

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/CLUSTER_CA_KEY_NAME/cryptoKeyVersions/VERSION

Nessa saída, VERSION é o número da nova versão da chave.

Crie uma nova AC raiz do cluster no pool de ACs do cluster:
```
gcloud privateca roots create CLUSTER_ROOT_CA_NAME \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=CLUSTER_CA_KEY_PATH \
    --subject="CN=cluster-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID
```
Substitua:
- CLUSTER_ROOT_CA_NAME: um nome para a nova CA raiz.
- CLUSTER_CA_POOL_NAME: o nome do pool de CA do cluster.
- CLUSTER_CA_KEY_PATH: o nome completo do recurso da nova versão da chave na saída da etapa anterior.
- ORGANIZATION: o nome da sua organização.

Encontre o nome completo do recurso da nova versão da chave da CA raiz de agregação:

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

O resultado será assim:

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/AGGREGATION_CA_KEY_NAME/cryptoKeyVersions/VERSION

Crie uma nova CA raiz de agregação no pool de CAs de agregação:
```
gcloud privateca roots create AGGREGATION_ROOT_CA_NAME \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=AGGREGATION_CA_KEY_PATH \
    --subject="CN=aggregation-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID
```
Substitua:
- AGGREGATION_ROOT_CA_NAME: um nome para a nova CA raiz de agregação.
- AGGREGATION_CA_POOL_NAME: o nome do pool de ACs de agregação.
- AGGREGATION_CA_KEY_PATH: o nome completo do recurso da nova versão da chave na saída da etapa anterior.

Receba o nome completo do recurso da nova versão da chave da CA raiz da API etcd:

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

O resultado será assim:

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/ETCD_API_CA_KEY_NAME/cryptoKeyVersions/VERSION

Crie uma nova AC raiz da API etcd no pool de ACs da API etcd:
```
gcloud privateca roots create ETCD_API_ROOT_CA_NAME \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=ETCD_API_CA_KEY_PATH \
    --subject="CN=etcd-api-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID
```
Substitua:
- ETCD_API_ROOT_CA_NAME: um nome para sua nova CA raiz da API etcd.
- ETCD_API_CA_POOL_NAME: o nome do pool de ACs da API etcd.
- ETCD_API_CA_KEY_PATH: o nome completo do recurso da nova versão da chave na saída da etapa anterior.

Encontre o nome completo do recurso da nova versão da chave da CA raiz do peer etcd:

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

O resultado será assim:

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/ETCD_PEER_CA_KEY_NAME/cryptoKeyVersions/VERSION

Crie uma nova CA raiz de peer do etcd no pool de CAs de peer do etcd:
```
gcloud privateca roots create ETCD_PEER_ROOT_CA_NAME \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=ETCD_PEER_CA_KEY_PATH \
    --subject="CN=etcd-peer-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID
```
Substitua:
- ETCD_PEER_ROOT_CA_NAME: um nome para a nova CA raiz do peer etcd.
- ETCD_PEER_CA_POOL_NAME: o nome do pool de ACs de peers do etcd.
- ETCD_PEER_CA_KEY_PATH: o nome completo do recurso da nova versão da chave na saída da etapa anterior.
Antes de continuar, propague as mudanças da CA raiz para o pacote de confiança do cluster seguindo as instruções na seção Reiniciar o plano de controle e os nós.

Substitua as CAs raiz originais pelas novas.

Depois de reiniciar o plano de controle e os nós, siga estas etapas:

Ative a nova CA raiz do cluster:

gcloud privateca roots enable CLUSTER_ROOT_CA_NAME \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Ative a nova CA raiz de agregação:

gcloud privateca roots enable AGGREGATION_ROOT_CA_NAME \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Ative a nova CA raiz da API etcd:

gcloud privateca roots enable ETCD_API_ROOT_CA_NAME \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Ative a nova CA raiz do peer etcd:

gcloud privateca roots enable ETCD_PEER_ROOT_CA_NAME \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Desative a CA raiz original do cluster:

gcloud privateca roots disable ORIGINAL_CLUSTER_ROOT_CA \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Substitua ORIGINAL_CLUSTER_ROOT_CA pelo nome da CA raiz original do cluster que você está fazendo a rotação.

Desative a CA raiz de agregação original:

gcloud privateca roots disable ORIGINAL_AGGREGATION_ROOT_CA \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Substitua ORIGINAL_AGGREGATION_ROOT_CA pelo nome da CA raiz de agregação original que você está fazendo a rotação.

Desative a CA raiz original da API etcd:

gcloud privateca roots disable ORIGINAL_ETCD_API_ROOT_CA \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Substitua ORIGINAL_ETCD_API_ROOT_CA pelo nome da CA raiz original da API etcd que você está fazendo a rotação.

Desative a CA raiz do peer etcd original:

gcloud privateca roots disable ORIGINAL_ETCD_PEER_ROOT_CA \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Substitua ORIGINAL_ETCD_PEER_ROOT_CA pelo nome da CA raiz do peer etcd original que você está fazendo a rotação.

Nesse ponto, as novas CAs raiz emitem todos os novos certificados no cluster. Para emitir novos certificados para o kubelet em cada nó, reinicie o plano de controle e os nós. Essa etapa é necessária porque os certificados kubelet têm um ciclo de vida longo.

Depois de vários dias em que o cluster permanece em um estado íntegro, é possível excluir as CAs raiz originais, conforme descrito na próxima seção.

Excluir as CAs raiz originais

Nesta seção, mostramos como excluir as CAs raiz originais. Antes de seguir estas etapas, verifique o seguinte:

O cluster permaneceu em um estado íntegro por vários dias depois que você substituiu as CAs raiz originais pelas novas.
Você substituiu todos os certificados emitidos pelas CAs raiz originais por novos certificados.

Para excluir as CAs raiz originais, use o comando gcloud privateca roots delete conforme descrito nas etapas a seguir. Nesses comandos, a flag --ignore-active-certificates exclui a CA após um período de carência, mesmo que ela tenha certificados não revogados ou não expirados.

Exclua a CA raiz original do cluster:

gcloud privateca roots delete ORIGINAL_CLUSTER_ROOT_CA \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

Substitua ORIGINAL_CLUSTER_ROOT_CA pelo nome da CA raiz original do cluster que você está fazendo a rotação.

Exclua a CA raiz de agregação original:

gcloud privateca roots delete ORIGINAL_AGGREGATION_ROOT_CA \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

Substitua ORIGINAL_AGGREGATION_ROOT_CA pelo nome da CA raiz de agregação original que você está fazendo a rotação.

Exclua a AC raiz original da API etcd:

gcloud privateca roots delete ORIGINAL_ETCD_API_ROOT_CA \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

Substitua ORIGINAL_ETCD_API_ROOT_CA pelo nome da CA raiz original da API etcd que você está fazendo a rotação.

Exclua a CA raiz original do peer do etcd:

gcloud privateca roots delete ORIGINAL_ETCD_PEER_ROOT_CA \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

Substitua ORIGINAL_ETCD_PEER_ROOT_CA pelo nome da CA raiz do peer etcd original que você está fazendo a rotação.

Opcional: propague as mudanças nas CAs raiz para o pacote de confiança do cluster. Para instruções, consulte a seção Reiniciar o plano de controle e os nós. Se você pular esta etapa, as CAs raiz originais serão removidas durante o próximo upgrade do plano de controle e da versão do nó.

Reiniciar o plano de controle e os nós

Quando você faz mudanças na configuração da CA raiz do cluster, como ativar, desativar ou revogar certificados de CA raiz, é necessário propagar essas mudanças para o pacote de confiança do cluster. Para propagar as mudanças no pacote de confiança do cluster, reinicie o plano de controle e (em alguns cenários) os nós.

Faça upgrade do plano de controle do cluster para a mesma versão que ele já usa.

Atenção: em clusters zonais, o plano de controle fica indisponível até que a operação de upgrade seja concluída. Nos clusters do Autopilot e nos clusters padrão regionais, o plano de controle permanece disponível.
1. Encontre a versão do GKE que o plano de controle já usa:
```
gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --format="value(currentMasterVersion)"
```
  Substitua:
  - CLUSTER_NAME: o nome do cluster do GKE.
  - CLUSTER_VERSION: a versão do GKE que o cluster já executa.
  - CLUSTER_PROJECT_ID: o ID do projeto do seu projeto de cluster.
2. Faça upgrade do plano de controle:
```
gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=CLUSTER_VERSION \
    --project=CLUSTER_PROJECT_ID
```
Se você gerar certificados manualmente usando o Kubernetes CertificateSigningRequests, reemita todos esses certificados e forneça os novos certificados aos clientes da API.
Para a rotação da CA raiz do cluster, acione a recriação de nós fazendo upgrade de cada um dos seus pools de nós para a mesma versão que eles já usam.
Atenção:o GKE começa imediatamente a recriar os nós para essa mudança usando a estratégia de upgrade de nós, independente das políticas de manutenção ativas. O GKE depende da disponibilidade de recursos para a mudança. Desativar os upgrades automáticos de nós não impede essa mudança. Prepare as cargas de trabalho executadas nos nós para interrupções antes de iniciar essa mudança.
1. Encontre a versão do GKE usada pelo pool de nós:
```
gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --format="value(version)"
```
  Substitua NODE_POOL_NAME pelo nome do pool de nós a ser atualizado.
2. Faça upgrade do pool de nós:
```
gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=NODE_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=CLUSTER_VERSION \
    --project=CLUSTER_PROJECT_ID
```

Se você executou as etapas desta seção durante uma rotação de CA, siga para a próxima fase da rotação, que é uma das seguintes seções desta página:

Substitua as CAs raiz originais pelas novas.
Exclua as CAs raiz originais.

Alternar CAs e chaves do plano de controle gerenciado pelo cliente Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Planejar rotações de credenciais

Antes de começar

Papéis e permissões necessárias

Limitações

Fazer a rotação das chaves de assinatura e verificação da conta de serviço

Fazer a rotação das CAs da autoridade do plano de controle do GKE

Criar novas versões de chave para as CAs

Criar novas CAs raiz

Substitua as CAs raiz originais pelas novas.

Excluir as CAs raiz originais

Reiniciar o plano de controle e os nós

A seguir

Alternar CAs e chaves do plano de controle gerenciado pelo cliente