Alterne as chaves e as ACs do plano de controlo geridas pelo cliente

.

Esta página mostra aos administradores de clusters e aos engenheiros de segurança como fazer a rotação das autoridades de certificação (ACs) e das chaves de assinatura de contas de serviço que configurou para a autoridade do plano de controlo do GKE.

Deve conhecer os seguintes conceitos:

Planeie rotações de credenciais

Esta página mostra como rodar os seguintes componentes das credenciais no seu plano de controlo:

  • A AC de raiz do cluster, a AC de raiz da agregação, a AC de raiz da API etcd e a AC de raiz do par etcd.
  • As chaves de assinatura e validação da conta de serviço do Kubernetes.

Também pode rodar as chaves de encriptação geridas pelo cliente que usou para encriptar os discos de arranque do plano de controlo, os discos etcd e a cópia de segurança interna do etcd que Google Cloud usa para recuperação de desastres. Para mais informações, consulte Rode as chaves de encriptação do disco de arranque do etcd e do plano de controlo.

Rode as suas credenciais para evitar a expiração da AC, mitigar os comprometimentos da versão da chave e como parte das práticas de segurança da sua organização. Para planear a frequência com que roda recursos de autoridade do plano de controlo do GKE específicos, considere o seguinte:

  • Por predefinição, os certificados do GKE assinados pelas CAs de 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 alteração manual da chave apenas se a sua organização tiver requisitos para a alteração da chave. Para minimizar as interrupções nas cargas de trabalho em execução, não configure a rotação automática de chaves para estas chaves.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  • Ative a API Google Kubernetes Engine.
    • Ative a API Google Kubernetes Engine
  • Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

  • Ter um cluster existente que use ACs autogeridas e chaves de contas de serviço

  • Identifique os IDs dos seguintes Google Cloud projetos:

    • Projeto da chave: o projeto que contém os recursos do Cloud KMS e do serviço de AC.
    • Projeto do cluster: o projeto que contém o seu cluster do GKE.

  • Para realizar as tarefas de validação nesta página, verifique se os seguintes registos de auditoria de acesso a dados estão ativados:

    • API Cloud Key Management Service (KMS): DATA_READ
    • Certificate Authority Service: ADMIN_READ

    Para ativar estes tipos de registos, consulte o artigo Ative os registos de auditoria de acesso a dados.

Funções e autorizações necessárias

Para receber as autorizações de que precisa para alternar as chaves e as ACs geridas pelo cliente, peça ao seu administrador para lhe conceder as seguintes funções de IAM:

Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Também pode conseguir as autorizações necessárias através de funções personalizadas ou outras funções predefinidas.

Limitações

As chaves assimétricas do Cloud KMS que usa para a assinatura e a validação da conta de serviço não suportam a rotação automática de chaves.

Alterne as chaves de assinatura e validação da conta de serviço

Quando configura a autoridade do plano de controlo do GKE, adiciona uma chave de assinatura da conta de serviço e chaves de validação da conta de serviço ao cluster. O GKE usa estas chaves para assinar e validar tokens de portador para contas de serviço do Kubernetes. Durante uma rotação, adiciona a nova chave à lista de chaves de validação da conta de serviço, aguarda que as alterações sejam propagadas 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 estes passos:

  1. Obtenha o nome completo do recurso da versão da chave 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 o seguinte:

    • CLUSTER_NAME: o nome do cluster.
    • CONTROL_PLANE_LOCATION: a localização do cluster.
    • CLUSTER_PROJECT_ID: o ID do projeto do projeto do cluster.

    O resultado é semelhante ao seguinte:

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

    Neste resultado, SIGNING_KEY_NAME é o nome da chave e ORIGINAL_SIGNING_KEY_VERSION é o número da versão da chave de assinatura original.

  2. Crie uma nova versão da chave para a 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 o seguinte:

    • SIGNING_KEY_NAME: o nome da chave de assinatura da conta de serviço.
    • KEYRING_NAME: o nome do conjunto de chaves que contém a chave.
    • CONTROL_PLANE_LOCATION: a Google Cloud localização do conjunto de chaves.
    • KEY_PROJECT_ID: o ID do projeto do seu projeto principal.

  3. Obtenha o nome do recurso completo 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 é semelhante ao seguinte:

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

    Neste resultado, SIGNING_KEY_NAME é o nome da chave e NEW_SIGNING_KEY_VERSION é o número da nova versão da chave de assinatura.

  4. Adicione a nova versão da chave ao conjunto de chaves de validação da conta de serviço para o 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 o seguinte:

    • ORIGINAL_KEY_VERSION_PATH: o nome completo do recurso da versão da chave de assinatura original da saída do primeiro passo desta secçã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 do passo anterior. Por exemplo, projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/2.

    Após a conclusão da operação de atualização do cluster, o novo caminho da versão da chave pode demorar até 10 minutos a propagar-se para o servidor da API Kubernetes e todos os pontos finais da API GKE.

  5. Para confirmar que o novo caminho da versão da chave está totalmente propagado, faça o seguinte:

    1. Obtenha o componente público das chaves de assinatura do cluster a partir da API GKE como um conjunto de chaves Web JSON (JWKS):

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

      O resultado é semelhante ao 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"
    }
  ]
}

      Esta saída tem de ter duas entradas de chave, o que indica que ambas as versões de chave estão disponíveis na API GKE. Se vir apenas uma entrada de chave, aguarde 10 minutos e tente novamente o comando.

    2. Ligue-se ao cluster para poder executar comandos kubectl:

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

    3. Obtenha o componente público das chaves de assinatura do cluster a partir do servidor da API Kubernetes como um JWKS:

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

      O resultado é semelhante ao 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"
    }
  ]
}

      Esta saída tem de ter duas entradas de chave, o que indica que ambas as versões da chave estão disponíveis no servidor da API Kubernetes. Se vir apenas uma entrada de chave, aguarde 10 minutos e tente novamente o comando.

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

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

    1. Crie uma ServiceAccount:

      kubectl create serviceaccount test-sa-1

    2. Crie um token para a ServiceAccount:

      kubectl create token test-sa-1

    3. Extraia um resumo assinado recentemente do registo:

      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)")
      1. Valide se a nova versão da chave de assinatura está a ser usada:
        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.

  8. Aguarde que todos os tokens no cluster que usa a versão da chave de assinatura da conta de serviço original expirem. Por predefinição, o tempo de vida do token é de uma hora, com um máximo configurável de 24 horas. Para verificar a duração do token configurada no seu 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

  9. Aguarde que a duração total do token configurada a partir do resultado do passo anterior seja ultrapassada. Após este período, todos os tokens associados no seu cluster usam a nova versão da chave de assinatura da conta de serviço.

  10. Remova a versão original da chave da lista de chaves de validação para o cluster:

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

  11. Opcional: desative a versão original da chave. Depois de verificar que a versão da chave original não está a ser usada e que o cluster está em bom estado, destrua a versão da chave.

    A menos que esteja a rodar 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 o artigo Destrua e restaure versões de chaves.

Depois de concluir estes passos, todos os tokens de contas de serviço novos e existentes no cluster são assinados pela nova versão da chave. O servidor da API rejeita todos os pedidos que usam um token de autorização com a versão da chave original, porque a versão da chave original não existe na configuração do cluster.

Rode as ACs de autoridade do plano de controlo do GKE

As secções seguintes mostram como rodar as ACs raiz que o cluster usa para a autoridade do plano de controlo do GKE.

Crie novas versões das chaves para as ACs

  1. Crie uma nova versão da chave para a chave da AC 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 o seguinte:

    • CLUSTER_CA_KEY_NAME: o nome da chave da AC raiz do cluster.
    • KEYRING_NAME: o nome do conjunto de chaves que contém a chave.
    • CONTROL_PLANE_LOCATION: a Google Cloud localização do conjunto de chaves. Esta é a mesma localização do seu cluster.
    • KEY_PROJECT_ID: o ID do projeto do seu projeto principal.

  2. Crie uma nova versão da chave para a chave de AC 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 para o cluster.

  3. Crie uma nova versão da chave 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.

  4. Crie uma nova versão da chave para a chave da AC de raiz do nó igual 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 AC raiz do par do etcd para o cluster.

Crie novas ACs raiz

  1. Obtenha o nome do recurso completo da nova versão da chave da AC 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 é semelhante ao seguinte:

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

    Neste resultado, VERSION é o número da nova versão da chave.

  2. Crie uma nova AC raiz do cluster no conjunto 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 o seguinte:

    • CLUSTER_ROOT_CA_NAME: um nome para a nova AC raiz.
    • CLUSTER_CA_POOL_NAME: o nome do conjunto de CA do cluster.
    • CLUSTER_CA_KEY_PATH: o nome completo do recurso da nova versão da chave a partir do resultado do passo anterior.
    • ORGANIZATION: o nome da sua organização.

  3. Obtenha o nome completo do recurso da nova versão da chave de AC 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 é semelhante ao seguinte:

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

  4. Crie uma nova CA de raiz de agregação no conjunto 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 o seguinte:

    • AGGREGATION_ROOT_CA_NAME: um nome para a nova AC raiz de agregação.
    • AGGREGATION_CA_POOL_NAME: o nome do conjunto de AC de agregação.
    • AGGREGATION_CA_KEY_PATH: o nome completo do recurso da nova versão da chave a partir do resultado do passo anterior.

  5. Obtenha o nome completo do recurso da nova versão da chave da AC 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 é semelhante ao seguinte:

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

  6. Crie uma nova AC raiz da API etcd no grupo 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 o seguinte:

    • ETCD_API_ROOT_CA_NAME: um nome para a nova AC raiz da API etcd.
    • ETCD_API_CA_POOL_NAME: o nome do conjunto de CA da API etcd.
    • ETCD_API_CA_KEY_PATH: o nome completo do recurso da nova versão da chave a partir do resultado do passo anterior.

  7. Obtenha o nome completo do recurso da nova versão da chave de AC raiz do par 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 é semelhante ao seguinte:

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

  8. Crie uma nova AC de raiz de pares etcd no grupo de ACs de pares 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 o seguinte:

    • ETCD_PEER_ROOT_CA_NAME: um nome para a nova AC raiz do par etcd.
    • ETCD_PEER_CA_POOL_NAME: o nome do grupo de ACs de pares do etcd.
    • ETCD_PEER_CA_KEY_PATH: o nome completo do recurso da nova versão da chave a partir do resultado do passo anterior.

  9. Antes de continuar, propague as alterações da AC raiz para o pacote de confiança do cluster seguindo as instruções na secção Reinicie o painel de controlo e os nós.

Substitua as ACs raiz originais pelas novas ACs raiz

Depois de reiniciar o plano de controlo e os nós, siga estes passos:

  1. Ative a nova AC raiz do cluster:

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

  2. Ative a nova AC 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

  3. Ative a nova AC 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

  4. Ative a nova AC de raiz de pares etcd:

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

  5. Desative a AC de 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 AC raiz do cluster original que está a rodar.

  6. Desative a AC de 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 AC raiz de agregação original que está a rodar.

  7. Desative a AC de 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 está a rodar.

  8. Desative a AC de raiz do nó 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 AC raiz do par etcd original que está a rodar.

  9. Neste ponto, as novas ACs de raiz emitem todos os novos certificados no cluster. Para emitir novos certificados para o kubelet em cada nó, reinicie o plano de controlo e os nós. Este passo é obrigatório porque os certificados kubelet têm um longo período de validade.

Após vários dias em que o cluster permanece num estado normal, pode eliminar as ACs de raiz originais, conforme descrito na secção seguinte.

Elimine as ACs de raiz originais

Esta secção mostra-lhe como eliminar as suas ACs raiz originais. Antes de seguir estes passos, verifique o seguinte:

  • O cluster permaneceu num estado de funcionamento durante vários dias após substituir as ACs raiz originais pelas novas ACs raiz.
  • Substituiu todos os certificados emitidos pelas ACs de raiz originais por novos certificados.

Para eliminar as ACs raiz originais, use o comando gcloud privateca roots delete, conforme descrito nos passos seguintes. Nestes comandos, a flag --ignore-active-certificates elimina a AC após um período de tolerância, mesmo que a AC tenha certificados não revogados ou não expirados.

  1. Elimine a AC de 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 AC raiz do cluster original que está a rodar.

  2. Elimine a AC de 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 AC raiz de agregação original que está a rodar.

  3. Elimine a CA de 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 está a rodar.

  4. Elimine a AC de raiz do nó 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 AC raiz do par etcd original que está a rodar.

  5. Opcional: propague as alterações às ACs de raiz para o pacote de fidedignidade do cluster. Para ver instruções, consulte a secção Reinicie o plano de controlo e os nós. Se ignorar este passo, as ACs raiz originais são removidas durante a atualização da versão do plano de controlo e do nó seguinte.

Reinicie o plano de controlo e os nós

Quando faz alterações à configuração da AC de raiz do cluster, como ativar ACs de raiz, desativar ACs de raiz ou revogar certificados, tem de propagar essas alterações ao pacote de confiança do cluster. Para propagar as alterações ao pacote de confiança do cluster, reinicie o plano de controlo e (em alguns cenários) os nós.

  1. Atualize o painel de controlo do cluster para a mesma versão que já usa.

    1. Encontre a versão do GKE que o plano de controlo já usa:

      gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --format="value(currentMasterVersion)"

      Substitua o seguinte:

      • CLUSTER_NAME: o nome do seu 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. Atualize o painel de controlo:

      gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=CLUSTER_VERSION \
    --project=CLUSTER_PROJECT_ID

  2. Se gerar manualmente certificados através de Kubernetes CertificateSigningRequests, reemita todos esses certificados e faculte os novos certificados aos clientes da API.

  3. Para a rotação da AC raiz do cluster apenas, acione a recriação do nó atualizando cada um dos seus conjuntos de nós para a mesma versão que já usam.

    1. Encontre a versão do GKE que o conjunto 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 conjunto de nós que quer atualizar.

    2. Atualize o node pool:

      gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=NODE_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=CLUSTER_VERSION \
    --project=CLUSTER_PROJECT_ID

Se executou os passos nesta secção durante uma rotação da AC, avance para a fase seguinte da rotação, que é uma das seguintes secções nesta página:

O que se segue?