O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

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 certificadoras (CAs) e as chaves de assinatura da conta de serviço que você configurou para a GKE control plane authority.

Você precisa conhecer os seguintes conceitos:

Planejar rotações de credenciais

Neste documento, mostramos como alternar os seguintes componentes de credencial no plano de controle:

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

Também é possível alternar as chaves de criptografia gerenciadas pelo cliente que você usou para criptografar os discos de inicialização do plano de controle, os discos etcd e o backup interno do etcd que o Google Cloud usa para recuperação de desastres. Para mais informações, consulte Alternar as chaves de criptografia do disco de inicialização do etcd e do plano de controle.

Faça a rotação das credenciais para evitar a expiração da CA, reduzir o comprometimento de versões de chaves e como parte das práticas de segurança da sua organização. Para planejar a frequência com que você vai alternar recursos específicos da GKE control plane authority, 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 de chaves manual somente se a 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 essas chaves.

Antes de começar

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

Ative a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Para usar a Google Cloud CLI nesta tarefa, instale e inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.
Observação:em instalações prévias da CLI gcloud, 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 CLI gcloud 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 use CAs autogerenciadas e chaves de conta de serviço e execute a versão 1.35.2-gke.1842000 ou posterior do GKE.
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 o cluster do GKE.
Para realizar as tarefas de validação neste documento, 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 alternar as CAs e as chaves gerenciadas pelo cliente, peça ao administrador para conceder a você os seguintes papéis do IAM:

Gerenciar chaves ou versões de chave: Administrador do Cloud KMS (roles/cloudkms.admin) no projeto de chave
Gerenciar CAs raiz: Administrador do CA Service (roles/privateca.admin) no projeto de chave
Configurar 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 usando papéis personalizados ou outros papéis predefinidos.

Limitações

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

Alternar as chaves de assinatura e verificação da conta de serviço

Ao configurar a GKE control plane authority, 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 ServiceAccounts do Kubernetes. Durante uma rotação, você adiciona a nova chave à lista de chaves de verificação da conta de serviço, aguarda a propagação das mudanças e, em seguida, substitui a chave de assinatura da conta de serviço pela nova chave.

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

Consiga 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á o seguinte:
```
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: o Google Cloud local do keyring.
- KEY_PROJECT_ID: o ID do projeto do seu projeto de chave.

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

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 da 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 de API Kubernetes e para todos endpoint de API do GKE.

Para confirmar se 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, na sigla em inglês):

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

O resultado será o seguinte:

{
  "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 de chave estão disponíveis na API GKE. Se você só encontrar uma entrada de chave, aguarde 10 minutos e tente o comando novamente.

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 de API Kubernetes como um JWKS:

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

O resultado será o seguinte:

{
  "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 de chave estão disponíveis no servidor de API Kubernetes. Se você só encontrar 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-keys=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)")

Confira 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)"

A saída é o caminho do recurso da nova versão da chave de assinatura.

Aguarde até que todos os tokens no cluster que usam a versão original da chave de assinatura da conta de serviço expirem. Por padrão, a vida útil do token é de uma hora, com um máximo configurável de 24 horas. Para verificar a vida útil do token configurada 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. Após esse período, todos os tokens vinculados no cluster usarão 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 que a versão original da chave não está sendo usada e que o cluster está íntegro, destrua a versão da chave.

A menos que você esteja alternando as 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 de API rejeita todas as solicitações que usam um token do portador com a versão original da chave, porque ela não existe na configuração do cluster.

Alternar as CAs da GKE control plane authority

As seções a seguir mostram como alternar as CAs raiz que o cluster usa para a GKE control plane authority.

Criar novas versões de chave para as CAs

Crie uma nova versão de chave para a chave de 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 de CA raiz do cluster.
- KEYRING_NAME: o nome do keyring que contém a chave.
- CONTROL_PLANE_LOCATION: o Google Cloud local do keyring. É igual ao local do cluster.
- KEY_PROJECT_ID: o ID do projeto do seu projeto de chave.

Crie uma nova versão para a chave de 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 de CA raiz de agregação do cluster.

Crie uma nova versão para a chave de 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 de CA raiz da API etcd para o cluster.

Crie uma nova versão de chave para a chave de CA raiz de peering do 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 de peering do etcd para o cluster.

Criar novas ACs raiz

Consiga o nome completo do recurso da nova versão da chave de 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á o seguinte:

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 CA raiz de cluster no pool de CAs 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 CAs do cluster.
- CLUSTER_CA_KEY_PATH: o nome completo do recurso da nova versão da chave da saída da etapa anterior.
- ORGANIZATION: o nome da 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á o seguinte:

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 CAs de agregação.
- AGGREGATION_CA_KEY_PATH: o nome completo do recurso da nova versão da chave da saída da etapa anterior.

Consiga o nome completo do recurso da nova versão da chave de 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á o seguinte:

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

Crie uma nova CA raiz da API etcd no pool de CAs 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 a nova CA raiz da API etcd.
- ETCD_API_CA_POOL_NAME: o nome do pool de CAs da API etcd.
- ETCD_API_CA_KEY_PATH: o nome completo do recurso da nova versão da chave da saída da etapa anterior.

Consiga o nome completo do recurso da nova versão da chave da CA raiz de peering do 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á o seguinte:

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 peering do etcd no pool de CAs de peering 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 de peering do etcd.
- ETCD_PEER_CA_POOL_NAME: o nome do pool de CAs de peering do etcd.
- ETCD_PEER_CA_KEY_PATH: o nome completo do recurso da nova versão da chave da 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.

Substituir 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 de peering do 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 do cluster original:

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 do cluster original que você está alternando.

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á alternando.

Desative a CA raiz da API etcd original:

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 da API etcd original que você está alternando.

Desative a CA raiz de peering do 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 par etcd original que você está alternando.

Nesse momento, 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 uma vida útil longa.

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 ACs 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 do cluster original:

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 do cluster original que você está alternando.

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á alternando.

Exclua a CA raiz da API etcd original:

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 da API etcd original que você está alternando.

Exclua a CA raiz de peering do etcd original:

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 par etcd original que você está alternando.

Opcional: propagar 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 essa etapa, as CAs raiz originais serão removidas durante o próximo upgrade da versão do plano de controle e do nó.

Reiniciar o plano de controle e os nós

Ao fazer alterações na configuração da CA raiz do cluster, como ativar ou desativar CAs raiz ou revogar certificados, é necessário propagar essas alterações 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
```
Somente para a rotação da CA raiz do cluster, acione a recriação de nós fazendo upgrade de cada um dos 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, independentemente 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 alteração.
1. Encontre a versão do GKE que o pool de nós usa:
```
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 que 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
```
Depois que o plano de controle e os nós terminarem o upgrade, atualize todos os clientes da API Kubernetes, como a CLI kubectl, para usar o pacote de confiança atualizado. Se você gerar certificados manualmente usando CertificateSigningRequests do Kubernetes, emita novamente todos esses certificados e forneça os novos certificados aos clientes da API.

Se você seguiu as etapas desta seção durante uma rotação de CA, prossiga para a próxima fase da rotação, que é uma das seguintes seções deste documento:

Substitua as ACs 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

Alternar as chaves de assinatura e verificação da conta de serviço

Alternar as CAs da GKE control plane authority

Criar novas versões de chave para as CAs

Criar novas ACs raiz

Substituir as CAs raiz originais pelas novas

Excluir as ACs raiz originais

Reiniciar o plano de controle e os nós

A seguir

Alternar CAs e chaves do plano de controle gerenciado pelo cliente