Rota las CA y las claves del plano de control administrado por el cliente

Estándar

Nota: En este documento, se usa una función de disponibilidad general llamada GKE control plane authority que solo está disponible para clientes de Google Cloud elegibles. Para solicitar acceso a esta función, comunícate con tu equipo de cuentas de Google Cloud .

En esta página, se muestra a los administradores de clústeres y a los ingenieros de seguridad cómo rotar las autoridades certificadoras (AC) y las claves de firma de la cuenta de servicio que configuraste para GKE control plane authority.

Debes conocer los siguientes conceptos:

• Administración de claves y credenciales.
• Rotación de credenciales administradas por el cliente.
• Consideraciones para las claves asimétricas.

Planifica rotaciones de credenciales

En este documento, se muestra cómo rotar los siguientes componentes de credenciales en tu plano de control:

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

También puedes rotar las claves de encriptación administradas por el cliente que usaste para encriptar los discos de arranque del plano de control, los discos de etcd y la copia de seguridad interna de etcd que Google Cloud usa para la recuperación ante desastres. Para obtener más información, consulta Rota las claves de encriptación del disco de arranque del plano de control y etcd.

Práctica recomendada:

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

Rota tus credenciales para evitar el vencimiento de la AC, mitigar las vulneraciones de las versiones de claves y como parte de las prácticas de seguridad de tu organización. Para planificar la frecuencia con la que rotas recursos específicos de GKE control plane authority, ten en cuenta lo siguiente:

• De forma predeterminada, los certificados de GKE firmados por las AC raíz en Certificate Authority Service (servicio de CA) vencen un año después de la fecha de creación.
• Las claves de Cloud Key Management Service (Cloud KMS) no vencen. Realiza una rotación de claves manual solo si tu organización tiene requisitos para la rotación de claves. 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 comenzar

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

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Para usar Google Cloud CLI en esta tarea, instala y, luego, inicializa la gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos de este documento.
  Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar la propiedad compute/region. Si usas principalmente clústeres zonales, configura compute/zone en su lugar. Cuando configuras 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 debas especificar la ubicación en ciertos comandos si la ubicación de tu clúster difiere de la predeterminada que estableciste.

• Tener un clúster existente que use claves de cuentas de servicio y AC autoadministradas y ejecute la versión 1.35.2-gke.1842000 o posterior de GKE.

• Identifica los IDs de los siguientes proyectos de Google Cloud :

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

• Para realizar las tareas de validación de este documento, verifica que estén habilitados los siguientes registros de auditoría de acceso a los datos:

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

  Para habilitar estos tipos de registros, consulta Habilita los registros de auditoría de acceso a los datos.

Roles y permisos requeridos

Para obtener los permisos que necesitas para rotar tus AC y claves administradas por el cliente, pídele a tu administrador que te otorgue los siguientes roles de IAM:

• Administra claves o versiones de claves: Administrador de Cloud KMS (roles/cloudkms.admin) en tu proyecto de claves
• Administra las AC raíz: Administrador del Servicio de AC (roles/privateca.admin) en tu proyecto clave
• Configura clústeres para usar credenciales nuevas: Administrador de clústeres de Kubernetes Engine (roles/container.clusterAdmin) en tu proyecto de clúster

Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

También puedes obtener los permisos necesarios mediante roles personalizados o cualquier otro rol predefinido.

Limitaciones

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

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

Cuando configuras GKE control plane authority, agregas 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 del portador de las ServiceAccounts de Kubernetes. Durante una rotación, agregas tu clave nueva a la lista de claves de verificación de la cuenta de servicio, esperas a que se propaguen los cambios y, luego, reemplazas la clave de firma de la cuenta de servicio por la clave nueva.

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

1. Obtén el nombre completo del recurso de la versión de clave 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)"
   

   Reemplaza lo siguiente:

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

   El resultado es similar a lo 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 nueva 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
   

   Reemplaza lo siguiente:

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

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

   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 es similar a lo 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. Agrega la versión de la clave nueva al conjunto de claves de verificación de la cuenta de servicio para el 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
   

   Reemplaza lo siguiente:

   • ORIGINAL_KEY_VERSION_PATH: Es el nombre completo del recurso de la versión original de la clave de firma del resultado 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: Es el nombre completo del recurso de la nueva versión de la clave de firma del resultado del paso anterior. Por ejemplo, projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/2.

   Después de que se complete la operación de actualización del clúster, la ruta de acceso de la versión de la clave nueva puede tardar hasta 10 minutos en propagarse al servidor de la API de Kubernetes y a cada extremo de API de GKE.

5. Para confirmar que la ruta de acceso de la nueva versión de la clave se propague 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 es similar a lo 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"
          }
        ]
      }
      

      Este resultado debe tener dos entradas de clave, lo que indica que ambas versiones de clave están disponibles en la API de GKE. Si solo ves una entrada de clave, espera 10 minutos y vuelve a ejecutar el comando.

   2. Conéctate al clúster para poder ejecutar comandos de 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 un JWKS:

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

      El resultado es similar a lo 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"
          }
        ]
      }
      

      Este resultado debe tener dos entradas de claves, lo que indica que ambas versiones de claves están disponibles en el servidor de la API de Kubernetes. Si solo ves una entrada de clave, espera 10 minutos y vuelve a ejecutar el comando.

6. Actualiza el clúster para usar la versión nueva de la clave como la 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-keys=NEW_KEY_VERSION_PATH
   

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

   1. Crea una ServiceAccount:

      kubectl create serviceaccount test-sa-1
      

   2. Crea un token para la ServiceAccount:

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

   4. Valida 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)"
      

      El resultado es la ruta de acceso al recurso de la nueva versión de la clave de firma.

8. Espera a que venza cada token del clúster que use la versión original de la clave de firma de la cuenta de servicio. De forma predeterminada, la vida útil del token es de una hora, con un máximo configurable de 24 horas. Para verificar la vida útil del token configurada 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 crearlos para que Kubernetes genere tokens nuevos que estén firmados por la versión de clave nueva.

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

10. Quita la versión de la 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. Inhabilita la versión de clave original (opcional). Después de verificar que no se use la versión de la clave original y que el clúster esté en buen estado, destruye la versión de la 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, consulta Destruye y restablece versiones de claves.

Después de completar estos pasos, cada token de cuenta de servicio nuevo y existente en 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 del portador con la versión de clave original, ya que esta no existe en la configuración del clúster.

Rota las AC de GKE control plane authority

En las siguientes secciones, se muestra cómo rotar las AC raíz que usa el clúster para GKE control plane authority.

Crea versiones de claves nuevas para las AC

1. Crea una versión de clave nueva para la clave de la 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
   

   Reemplaza lo siguiente:

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

2. Crea una versión de clave nueva para la clave de la AC 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
   

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

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

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

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

4. Crea una versión de clave nueva para la clave de la AC raíz de par de etcd:

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

   Reemplaza ETCD_PEER_CA_KEY_NAME por el nombre de la clave de la AC raíz de intercambio de tráfico de etcd para el clúster.

Crea nuevas AC 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 es similar a lo 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 versión de la clave nueva.

2. Crea una nueva AC raíz del clúster en el grupo de AC del 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
   

   Reemplaza lo siguiente:

   • CLUSTER_ROOT_CA_NAME: Es un nombre para tu nueva AC raíz.
   • CLUSTER_CA_POOL_NAME: Es el nombre del grupo de AC del clúster.
   • CLUSTER_CA_KEY_PATH: Es el nombre completo del recurso de la versión de clave nueva del resultado del paso anterior.
   • ORGANIZATION: Es el nombre de tu organización.

3. Obtén el nombre de recurso completo de la nueva versión de la clave de la AC 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 es similar a lo 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 CA 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
   

   Reemplaza lo siguiente:

   • AGGREGATION_ROOT_CA_NAME: Es un nombre para tu nueva AC raíz de agregación.
   • AGGREGATION_CA_POOL_NAME: Es el nombre del grupo de AC de agregación.
   • AGGREGATION_CA_KEY_PATH: Es el nombre completo del recurso de la versión de clave nueva del resultado del paso anterior.

5. Obtén el nombre de recurso completo de la nueva versión de la clave de la AC raíz de la API de 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 es similar a lo siguiente:

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

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

   Reemplaza lo siguiente:

   • ETCD_API_ROOT_CA_NAME: Es un nombre para la nueva AC raíz de la API de etcd.
   • ETCD_API_CA_POOL_NAME: Es el nombre del grupo de AC de la API de etcd.
   • ETCD_API_CA_KEY_PATH: Es el nombre completo del recurso de la versión de clave nueva del resultado del paso anterior.

7. Obtén el nombre de recurso completo de la nueva versión de la clave de la AC raíz de par 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 es similar a lo siguiente:

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

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

   Reemplaza lo siguiente:

   • ETCD_PEER_ROOT_CA_NAME: Es un nombre para tu nueva AC raíz de par de etcd.
   • ETCD_PEER_CA_POOL_NAME: el nombre del grupo de AC de par de etcd.
   • ETCD_PEER_CA_KEY_PATH: Es el nombre completo del recurso de la versión de clave nueva del resultado 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 Reinicia el plano de control y los nodos.

Reemplaza 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 par 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 AC 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
   

   Reemplaza ORIGINAL_CLUSTER_ROOT_CA por el nombre de la CA raíz del clúster original que rotarás.

6. Inhabilita la AC 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
   

   Reemplaza ORIGINAL_AGGREGATION_ROOT_CA por el nombre de la CA raíz de agregación original que rotarás.

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

   Reemplaza ORIGINAL_ETCD_API_ROOT_CA por el nombre de la CA raíz de la API de etcd original que rotarás.

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

   Reemplaza ORIGINAL_ETCD_PEER_ROOT_CA por el nombre de la CA raíz de par de etcd original que rotarás.

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

Después de varios días en los que el clúster permanece en un estado correcto, puedes borrar las CAs raíz originales, como se describe en la siguiente sección.

Borra las AC raíz originales

En esta sección, se muestra cómo borrar las AC raíz originales. Antes de seguir estos pasos, verifica lo siguiente:

• El clúster permaneció en un estado correcto durante varios días después de que reemplazaste las AC raíz originales por las nuevas.
• Reemplazaste todos los certificados emitidos por las AC raíz originales por certificados nuevos.

Para borrar las AC raíz originales, usa el comando gcloud privateca roots delete, como se describe en los siguientes pasos. En estos comandos, la marca --ignore-active-certificates borra la CA después de un período de gracia, incluso si la CA tiene certificados no revocados o no vencidos.

1. Borra 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
   

   Reemplaza ORIGINAL_CLUSTER_ROOT_CA por el nombre de la CA raíz del clúster original que rotarás.

2. Borra la CA 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
   

   Reemplaza ORIGINAL_AGGREGATION_ROOT_CA por el nombre de la CA raíz de agregación original que rotarás.

3. Borra la CA raíz de la API de 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
   

   Reemplaza ORIGINAL_ETCD_API_ROOT_CA por el nombre de la CA raíz de la API de etcd original que rotarás.

4. Borra la CA raíz de par 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
   

   Reemplaza ORIGINAL_ETCD_PEER_ROOT_CA por el nombre de la CA raíz de par de etcd original que rotarás.

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

Correcto: Rotaste todas las AC raíz en tu plano de control. Todos los certificados de la AC en tu clúster se emiten por tus AC raíz nuevas. Las AC raíz originales ya no existen en el paquete de confianza del clúster.

Reinicia el plano de control y los nodos

Cuando realices cambios en la configuración de la AC raíz de tu clúster, como habilitar o inhabilitar AC raíz, o revocar certificados, debes propagar esos cambios al paquete de confianza del clúster. Para propagar los cambios en el paquete de confianza del clúster, debes reiniciar 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 usa.

   Precaución: En los clústeres zonales, el plano de control deja de estar disponible hasta que se completa la operación de actualización. En los clústeres de Autopilot y Standard regionales, el plano de control sigue 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)"
      

      Reemplaza lo siguiente:

      • CLUSTER_NAME: Es el nombre del clúster de GKE.
      • CLUSTER_VERSION: Es la versión de GKE que ya ejecuta el clúster.
      • CLUSTER_PROJECT_ID: Es 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. Solo para la rotación de 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 usan.

   Precaución: GKE comienza a volver a crear los nodos para este cambio de inmediato con la estrategia de actualización de nodos, sin importar las políticas de mantenimiento activas. GKE depende de la disponibilidad de recursos para el cambio. Inhabilitar las actualizaciones automáticas de nodos no evita este cambio. Prepara las cargas de trabajo que se ejecutan en tus nodos para la interrupción 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)"
      

      Reemplaza NODE_POOL_NAME por el nombre del grupo de nodos que deseas 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
      

3. Después de que el plano de control y los nodos terminen de actualizarse, actualiza los clientes de API de Kubernetes, como la CLI de kubectl, para usar el paquete de confianza actualizado. Si generas certificados de forma manual con CertificateSigningRequests de Kubernetes, vuelve a emitir todos esos certificados y proporciona los nuevos a los clientes de la API.

Si realizaste los pasos de esta sección durante una rotación de la AC, continúa con la siguiente fase de la rotación, que es una de las siguientes secciones de este documento:

• Reemplaza las AC raíz originales por las nuevas.
• Borra las AC raíz originales.

¿Qué sigue?

• Rota las claves de encriptación del disco de arranque del plano de control y de etcd
• Verifica la emisión y el uso de la identidad