Alternar las ACs y las claves del plano de control gestionado por el cliente

Estándar

---

Nota: En este documento se usa una función de disponibilidad general llamada Autoridad del plano de control de GKE, que solo está disponible para los clientes que cumplan los requisitos. Google Cloud Para solicitar acceso a esta función, póngase en contacto con el Google Cloud equipo de su cuenta

.

En esta página se explica a los administradores de clústeres y a los ingenieros de seguridad cómo rotar las autoridades de certificación (CAs) y las claves de firma de cuentas de servicio que haya configurado para la autoridad del plano de control de GKE.

Debes familiarizarte con los siguientes conceptos:

• Gestión de claves y credenciales.
• Rotación de credenciales gestionadas por el cliente.
• Consideraciones sobre las claves asimétricas

Planificar rotaciones de credenciales

En esta página se explica cómo rotar los siguientes componentes de credenciales en tu plano de control:

• La AC raíz del clúster, la AC raíz de agregación, la AC raíz de la API de etcd y la AC raíz del peer de etcd.
• Las claves de firma y verificación de ServiceAccount de Kubernetes.

También puedes rotar las claves de cifrado gestionadas por el cliente que hayas usado para cifrar los discos de arranque del plano de control, los discos de etcd y la copia de seguridad interna de etcd que Google Cloud se usa para la recuperación ante desastres. Para obtener más información, consulta Rotar las claves de cifrado del disco de arranque de etcd y del plano de control.

Práctica recomendada:

Valida tus procedimientos de rotación de claves y credenciales antes de que se produzca un incidente real.

Rota tus credenciales para evitar que caduquen las autoridades de certificación, para mitigar las vulneraciones de versiones de claves y como parte de las prácticas de seguridad de tu organización. Para planificar la frecuencia con la que vas a rotar recursos de autoridad específicos del plano de control de GKE, ten en cuenta lo siguiente:

• De forma predeterminada, los certificados de GKE firmados por las ACs raíz del servicio de autoridades de certificación (CA Service) caducan un año después de la fecha de creación.
• Las claves de Cloud Key Management Service (Cloud KMS) no caducan. Realiza un cambio de clave manual solo si tu organización tiene requisitos para ello. Para minimizar las interrupciones en las cargas de trabajo en ejecución, no configures la rotación automática de claves para estas claves.

Antes de empezar

Antes de empezar, asegúrate de haber realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.
  Nota: Si ya tienes instalada la CLI de gcloud, asegúrate de definir la compute/region propiedad. Si usas principalmente clústeres zonales, define compute/zone en su lugar. Si defines una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que tengas que especificar la ubicación en determinados comandos si la ubicación de tu clúster es diferente de la predeterminada que hayas definido.

• Tener un clúster que use ACs y claves de cuentas de servicio autogestionadas

• Identifica los IDs de los siguientes proyectos: Google Cloud

  • Proyecto de claves: el proyecto que contiene tus recursos de Cloud KMS y del servicio de AC.
  • Proyecto de clúster: el proyecto que contiene tu clúster de GKE.

• Para realizar las tareas de validación de esta página, comprueba que los siguientes registros de auditoría de acceso a los datos estén habilitados:

  • API de Cloud Key Management Service (KMS): DATA_READ
  • Servicio de Autoridades de Certificación: ADMIN_READ

  Para habilitar estos tipos de registros, consulta el artículo sobre cómo habilitar registros de auditoría de acceso a datos.

Roles y permisos necesarios

Para obtener los permisos que necesitas para rotar tus CAs y claves gestionadas por el cliente, pide a tu administrador que te conceda los siguientes roles de gestión de identidades y accesos:

• Gestionar claves o versiones de claves: Administrador de Cloud KMS (roles/cloudkms.admin) en tu proyecto de claves
• Gestionar ACs raíz: Administrador del servicio de ACs (roles/privateca.admin) en tu proyecto de claves
• Configura los clústeres para que usen las nuevas credenciales: Administrador de clústeres de Kubernetes Engine (roles/container.clusterAdmin) en el proyecto de tu clúster

Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

También puedes conseguir los permisos necesarios a través de roles personalizados u otros roles predefinidos.

Limitaciones

Las claves asimétricas de Cloud KMS que usas para firmar y verificar cuentas de servicio no admiten la rotación automática de claves.

Rotar las claves de firma y verificación de la cuenta de servicio

Cuando configuras la autoridad del plano de control de GKE, añades una clave de firma de cuenta de servicio y claves de verificación de cuenta de servicio a tu clúster. GKE usa estas claves para firmar y validar tokens de portador de cuentas de servicio de Kubernetes. Durante una rotación, añade la nueva clave a la lista de claves de verificación de la cuenta de servicio, espera a que se propaguen los cambios y, a continuación, sustituye la clave de firma de la cuenta de servicio por la nueva clave.

Para rotar las claves de la cuenta de servicio, sigue estos pasos:

1. Obtén el nombre completo del recurso de la versión original de la clave de firma de la cuenta de servicio:

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

   Haz los cambios siguientes:

   • CLUSTER_NAME: el nombre de tu clúster.
   • CONTROL_PLANE_LOCATION: la ubicación del clúster.
   • CLUSTER_PROJECT_ID: el ID del proyecto del clúster.

   El resultado debería ser similar al siguiente:

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

   En este resultado, SIGNING_KEY_NAME es el nombre de la clave y ORIGINAL_SIGNING_KEY_VERSION es el número de la versión original de la clave de firma.

2. Crea una versión de clave para la clave de firma de la cuenta de servicio:

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

   Haz los cambios siguientes:

   • SIGNING_KEY_NAME: el nombre de la clave de firma de la cuenta de servicio.
   • KEYRING_NAME: el nombre del conjunto de claves que contiene la clave.
   • CONTROL_PLANE_LOCATION: la Google Cloud ubicación del conjunto de claves.
   • KEY_PROJECT_ID: el ID del proyecto de tu proyecto de clave.

3. Obtén el nombre completo del recurso de la nueva versión de la clave:

   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
   

   El resultado debería ser similar al siguiente:

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

   En este resultado, SIGNING_KEY_NAME es el nombre de la clave y NEW_SIGNING_KEY_VERSION es el número de la nueva versión de la clave de firma.

4. Añade la nueva versión de la clave al conjunto de claves de verificación de la cuenta de servicio del clúster:

   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
   

   Haz los cambios siguientes:

   • ORIGINAL_KEY_VERSION_PATH: nombre completo del recurso de la versión de la clave de firma original de la salida del primer paso de esta sección. Por ejemplo, projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/1.
   • NEW_KEY_VERSION_PATH: el nombre completo del recurso de la nueva versión de la clave de firma de la salida del paso anterior. Por ejemplo, projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/2.

   Una vez que se haya completado la operación de actualización del clúster, la nueva ruta de la versión de la clave puede tardar hasta 10 minutos en propagarse al servidor de la API de Kubernetes y a todos los endpoints de la API de GKE.

5. Para confirmar que la nueva ruta de la versión de la clave se ha propagado por completo, haz lo siguiente:

   1. Obtén el componente público de las claves de firma del clúster de la API de GKE como un conjunto de claves web JSON (JWKS):

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

      El resultado debería ser similar al siguiente:

      {
        "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 salida debe tener dos entradas de clave, lo que indica que ambas versiones de la clave están disponibles en la API de GKE. Si solo ves una entrada de clave, espera 10 minutos y vuelve a intentar el comando.

   2. Conéctate al clúster para poder ejecutar comandos kubectl:

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

   3. Obtén el componente público de las claves de firma del clúster del servidor de la API de Kubernetes como JWKS:

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

      El resultado debería ser similar al siguiente:

      {
        "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 salida debe tener dos entradas de clave, lo que indica que ambas versiones de la clave están disponibles en el servidor de la API de Kubernetes. Si solo ves una entrada de clave, espera 10 minutos y vuelve a intentar el comando.

6. Actualiza el clúster para que use la nueva versión de la clave como clave de firma de la cuenta de servicio:

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

7. Verifica que los nuevos tokens de cuenta de servicio usen la nueva versión de la clave:

   1. Crea una ServiceAccount:

      kubectl create serviceaccount test-sa-1
      

   2. Crea un token para la cuenta de servicio:

      kubectl create token test-sa-1
      

   3. Extrae un resumen firmado recientemente de 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)")
      

      1. Comprueba que se esté usando la nueva versión de la clave de firma:

        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. Espera a que caduque cada token del clúster que use la versión original de la clave de firma de la cuenta de servicio. De forma predeterminada, el tiempo de vida del token es de una hora, con un máximo configurable de 24 horas. Para comprobar el tiempo de vida del token configurado en tu clúster, ejecuta el siguiente comando:

   kubectl get pods -A -o json | jq -r '.items[]?.spec?.volumes[]?.projected?.sources[]?.serviceAccountToken?.expirationSeconds | select(. != null)' | sort -nr | head -n 1
   

   Nota: Si almacenas tokens de ServiceAccount en Secrets, vuelve a crear los Secrets para que Kubernetes genere tokens nuevos firmados con la nueva versión de la clave.

9. Espera a que transcurra el tiempo de vida del token configurado en el paso anterior. Una vez transcurrido este periodo, todos los tokens vinculados de tu clúster usarán la nueva versión de la clave de firma de la cuenta de servicio.

10. Elimina la versión de clave original de la lista de claves de verificación del clúster:

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

11. Opcional: Inhabilita la versión de clave original. Una vez que hayas verificado que no se está usando la versión de clave original y que el clúster está en buen estado, destruye la versión de clave.

    A menos que rotes las claves en respuesta a un evento crítico, te recomendamos que esperes unos días antes de destruir la versión original de la clave. Para obtener más información, consulte Destruir y restaurar versiones de clave.

Una vez que hayas completado estos pasos, cada token de cuenta de servicio nuevo y actual de tu clúster se firmará con la nueva versión de la clave. El servidor de la API rechaza cualquier solicitud que use un token de portador con la versión original de la clave, ya que esta versión no existe en la configuración del clúster.

Alternar las autoridades de certificación del plano de control de GKE

En las siguientes secciones se muestra cómo rotar las CAs raíz que usa el clúster para la autoridad del plano de control de GKE.

Crear versiones de clave para las CAs

1. Crea una versión de clave para la clave de CA raíz del clúster:

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

   Haz los cambios siguientes:

   • CLUSTER_CA_KEY_NAME: el nombre de la clave de la AC raíz del clúster.
   • KEYRING_NAME: el nombre del conjunto de claves que contiene la clave.
   • CONTROL_PLANE_LOCATION: la Google Cloud ubicación del conjunto de claves. Es la misma que la ubicación de tu clúster.
   • KEY_PROJECT_ID: el ID del proyecto de tu proyecto de clave.

2. Crea una versión de clave para la clave de CA raíz de agregación:

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

   Sustituye AGGREGATION_CA_KEY_NAME por el nombre de la clave de la AC raíz de agregación del clúster.

3. Crea una versión de clave para la clave de CA raíz de la API etcd:

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

   Sustituye ETCD_API_CA_KEY_NAME por el nombre de la clave de la AC raíz de la API de etcd del clúster.

4. Crea una versión de clave para la clave de CA raíz del peer de etcd:

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

   Sustituye ETCD_PEER_CA_KEY_NAME por el nombre de la clave de la AC raíz del peer de etcd del clúster.

Crear nuevas ACs raíz

1. Obtén el nombre completo del recurso de la nueva versión de la clave de la AC raíz del clúster:

   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
   

   El resultado debería ser similar al siguiente:

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

   En este resultado, VERSION es el número de la nueva versión de la clave.

2. Crea una nueva CA raíz de clúster en el grupo de CAs de clúster:

   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
   

   Haz los cambios siguientes:

   • CLUSTER_ROOT_CA_NAME: el nombre de la nueva CA raíz.
   • CLUSTER_CA_POOL_NAME: nombre del pool de CA del clúster.
   • CLUSTER_CA_KEY_PATH: el nombre completo del recurso de la nueva versión de la clave, que se obtiene en el paso anterior.
   • ORGANIZATION: el nombre de tu organización.

3. Obtén el nombre completo del recurso de la nueva versión de la clave de la CA raíz de agregación:

   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
   

   El resultado debería ser similar al siguiente:

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

4. Crea una nueva CA raíz de agregación en el grupo de CAs de agregación:

   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
   

   Haz los cambios siguientes:

   • AGGREGATION_ROOT_CA_NAME: el nombre de la nueva CA raíz de agregación.
   • AGGREGATION_CA_POOL_NAME: el nombre del grupo de AC de agregación.
   • AGGREGATION_CA_KEY_PATH: el nombre completo del recurso de la nueva versión de la clave de la salida del paso anterior.

5. Obtén el nombre completo del recurso de la nueva versión de la clave de la AC raíz de la 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
   

   El resultado debería ser similar al siguiente:

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

6. Crea una nueva AC raíz de la API de etcd en el grupo de ACs de la API de 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
   

   Haz los cambios siguientes:

   • ETCD_API_ROOT_CA_NAME: nombre de la nueva CA raíz de la API de etcd.
   • ETCD_API_CA_POOL_NAME: el nombre del grupo de CA de la API de etcd.
   • ETCD_API_CA_KEY_PATH: el nombre completo del recurso de la nueva versión de la clave de la salida del paso anterior.

7. Obtén el nombre completo del recurso de la nueva versión de la clave de CA raíz del peer de 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
   

   El resultado debería ser similar al siguiente:

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

8. Crea una CA raíz de peer de etcd en el grupo de CA de peer de 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
   

   Haz los cambios siguientes:

   • ETCD_PEER_ROOT_CA_NAME: nombre de la nueva CA raíz de peer de etcd.
   • ETCD_PEER_CA_POOL_NAME: el nombre del grupo de autoridades de certificación de peer de etcd.
   • ETCD_PEER_CA_KEY_PATH: el nombre completo del recurso de la nueva versión de la clave de la salida del paso anterior.

9. Antes de continuar, propaga los cambios de la AC raíz al paquete de confianza del clúster siguiendo las instrucciones de la sección Reiniciar el plano de control y los nodos.

Sustituir las AC raíz originales por las nuevas

Después de reiniciar el plano de control y los nodos, sigue estos pasos:

1. Habilita la nueva CA raíz del clúster:

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

2. Habilita la nueva CA raíz de agregación:

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

3. Habilita la nueva CA raíz de la API de 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. Habilita la nueva CA raíz de peer de 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. Inhabilita la CA raíz del clúster original:

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

   Sustituye ORIGINAL_CLUSTER_ROOT_CA por el nombre de la CA raíz del clúster original que vas a rotar.

6. Inhabilita la CA raíz de agregación original:

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

   Sustituye ORIGINAL_AGGREGATION_ROOT_CA por el nombre de la CA raíz de agregación original que vas a rotar.

7. Inhabilita la CA raíz de la 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
   

   Sustituye ORIGINAL_ETCD_API_ROOT_CA por el nombre de la CA raíz de la API de etcd original que vas a rotar.

8. Inhabilita la CA raíz del peer de 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
   

   Sustituye ORIGINAL_ETCD_PEER_ROOT_CA por el nombre de la CA raíz del peer de etcd original que vas a rotar.

9. En este punto, las nuevas AC raíz emiten todos los certificados nuevos del clúster. Para emitir nuevos certificados para kubelet en cada nodo, reinicia el plano de control y los nodos. Este paso es obligatorio porque los certificados kubelet tienen una larga duración.

Después de varios días en los que el clúster se mantenga en buen estado, puede eliminar las AC raíz originales, tal como se describe en la siguiente sección.

Eliminar las CAs raíz originales

En esta sección se explica cómo eliminar las CAs raíz originales. Antes de seguir estos pasos, comprueba lo siguiente:

• El clúster se mantuvo en buen estado durante varios días después de sustituir las autoridades de certificación raíz originales por las nuevas.
• Has sustituido todos los certificados emitidos por las AC raíz originales por certificados nuevos.

Para eliminar las ACs raíz originales, usa el comando gcloud privateca roots delete, tal como se describe en los pasos siguientes. En estos comandos, la marca --ignore-active-certificates elimina la AC después de un periodo de gracia, aunque la AC tenga certificados no revocados o no caducados.

1. Elimina la CA raíz del clúster 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
   

   Sustituye ORIGINAL_CLUSTER_ROOT_CA por el nombre de la CA raíz del clúster original que vas a rotar.

2. Elimina la AC raíz de agregación 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
   

   Sustituye ORIGINAL_AGGREGATION_ROOT_CA por el nombre de la CA raíz de agregación original que vas a rotar.

3. Elimina la AC raíz de la 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
   

   Sustituye ORIGINAL_ETCD_API_ROOT_CA por el nombre de la CA raíz de la API de etcd original que vas a rotar.

4. Elimina la CA raíz del peer de 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
   

   Sustituye ORIGINAL_ETCD_PEER_ROOT_CA por el nombre de la CA raíz del peer de etcd original que vas a rotar.

5. Opcional: Propaga los cambios a las CAs raíz al paquete de confianza del clúster. Para obtener instrucciones, consulta la sección Reiniciar el plano de control y los nodos. Si omite este paso, las CAs raíz originales se eliminarán durante la próxima actualización de la versión del plano de control y del nodo.

Correcto: has rotado todas las CAs raíz de tu plano de control. Todas las CA de su clúster están emitidas por sus nuevas CAs raíz. Las CAs raíz originales ya no están en el paquete de confianza del clúster.

Reiniciar el plano de control y los nodos

Cuando hagas cambios en la configuración de la CA raíz de tu clúster, como habilitar o inhabilitar CAs raíz o revocar certificados, debes propagar esos cambios al paquete de confianza del clúster. Para propagar los cambios al paquete de confianza del clúster, reinicia el plano de control y (en algunos casos) los nodos.

1. Actualiza el plano de control del clúster a la misma versión que ya utiliza.

   Precaución: En los clústeres zonales, el plano de control no estará disponible hasta que se complete la operación de actualización. En los clústeres de Autopilot y los clústeres estándar regionales, el plano de control sigue estando disponible.

   1. Busca la versión de GKE que ya usa el plano de control:

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

      Haz los cambios siguientes:

      • CLUSTER_NAME: el nombre de tu clúster de GKE.
      • CLUSTER_VERSION: la versión de GKE que ya ejecuta el clúster.
      • CLUSTER_PROJECT_ID: el ID del proyecto de tu proyecto de clúster.

   2. Actualiza el plano de control:

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

2. Si generas certificados manualmente mediante Kubernetes CertificateSigningRequests, vuelve a emitir todos esos certificados y proporciona los nuevos certificados a los clientes de la API.

3. Si solo quieres rotar la AC raíz del clúster, activa la recreación de nodos actualizando cada uno de tus grupos de nodos a la misma versión que ya utilizan.

   Precaución: GKE empieza inmediatamente a recrear los nodos para este cambio mediante la estrategia de actualización de nodos, independientemente de las políticas de mantenimiento activas. GKE depende de la disponibilidad de recursos para el cambio. Deshabilitar las actualizaciones automáticas de nodos no impide este cambio. Prepara las cargas de trabajo que se ejecutan en tus nodos para que no se vean afectadas antes de iniciar este cambio.

   1. Busca la versión de GKE que usa el grupo de nodos:

      gcloud container node-pools describe NODE_POOL_NAME \
          --cluster=CLUSTER_NAME \
          --location=CONTROL_PLANE_LOCATION \
          --project=CLUSTER_PROJECT_ID \
          --format="value(version)"
      

      Sustituye NODE_POOL_NAME por el nombre del grupo de nodos que quieras actualizar.

   2. Actualiza el grupo de nodos:

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

Si has seguido los pasos de esta sección durante una rotación de la CA, ve a la siguiente fase de la rotación, que es una de las siguientes secciones de esta página:

• Sustituye las ACs raíz originales por las nuevas.
• Elimina las ACs raíz originales.

Siguientes pasos

• Rotar las claves de cifrado del disco de arranque de etcd y del plano de control
• Verificar la emisión y el uso de la identidad