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

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 cuentas de servicio que configuraste para la autoridad del plano de control de GKE.

Debes conocer los siguientes conceptos:

Planifica las rotaciones de credenciales

En esta página, 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.
  • Son las claves de firma y verificación de 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 Cómo rotar las claves de encriptación del disco de arranque de etcd y del plano de control.

Rota tus credenciales para evitar el vencimiento de la CA, mitigar las vulneraciones de versiones de claves y como parte de las prácticas de seguridad de tu organización. Para planificar con qué frecuencia rotarás los recursos específicos de la autoridad del plano de control de GKE, ten en cuenta lo siguiente:

  • De forma predeterminada, los certificados de GKE firmados por las AC raíz en Certificate Authority Service (CA Service) 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
  • Si quieres usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.

  • Tener un clúster existente que use AC y claves de cuenta de servicio administradas por el usuario

  • Identifica los IDs de los siguientes proyectos Google Cloud :

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

  • Para realizar las tareas de validación en esta página, 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 CAs y claves administradas por el cliente, pídele a tu administrador que te otorgue los siguientes roles de IAM:

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 la autoridad del plano de control de GKE, agregas una clave de firma de la cuenta de servicio y claves de verificación de la cuenta de servicio a tu clúster. GKE usa estas claves para firmar y validar tokens de portador para las cuentas de servicio 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 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 este:

    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: Es el nombre del llavero de claves que contiene la clave.
    • CONTROL_PLANE_LOCATION: Es la Google Cloud ubicación del llavero de claves.
    • KEY_PROJECT_ID: Es el ID del proyecto de tu proyecto de claves.

  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 es similar a este:

    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 nueva versión de la clave 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 de la clave de firma original que se obtuvo en el 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 que se obtuvo en el 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, es posible que la nueva ruta de acceso de la versión de la clave tarde hasta 10 minutos en propagarse al servidor de la API de Kubernetes y a todos extremo de API de GKE.

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

    1. Obtén el componente público de las claves de firma del clúster desde 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 este:

      {
  "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 la 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 este:

      {
  "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 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 ejecutar el comando.

  6. Actualiza el clúster para usar 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 tokens de la cuenta de servicio nueva usen la versión de clave nueva:

    1. Crea un ServiceAccount:

      kubectl create serviceaccount test-sa-1

    2. Crea un token para 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)")
      1. 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)"
  ```
The output is the resource path of the new signing key version.

  8. Espera a que venza cada token del clúster que usa la versión de clave de firma de la cuenta de servicio original. 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 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

  9. Espera a que transcurra el tiempo de vida útil 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 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. Después de verificar 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, 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 de portador con la versión de clave original, ya que esta no existe en la configuración del clúster.

Rota las CA de la autoridad del plano de control de GKE

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

Crea versiones de claves nuevas para las CA

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

    Reemplaza lo siguiente:

    • CLUSTER_CA_KEY_NAME: Es el nombre de la clave de la CA raíz del clúster.
    • KEYRING_NAME: Es el nombre del llavero de claves que contiene la clave.
    • CONTROL_PLANE_LOCATION: Es la Google Cloud ubicación del llavero de claves. Esta 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 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

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

  3. Crea una nueva versión de la clave raíz de la CA 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 CA raíz de la API de etcd para el clúster.

  4. Crea una versión de clave nueva para la clave de CA raíz del 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 CA raíz del par de etcd para el clúster.

Crear nuevas AC raíz

  1. Obtén el nombre completo del recurso de la nueva versión de la clave de la CA 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 este:

    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 del clúster en el grupo de CA 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 CA raíz.
    • CLUSTER_CA_POOL_NAME: Es el nombre del grupo de entidades certificadoras del clúster.
    • CLUSTER_CA_KEY_PATH: Es el nombre completo del recurso de la nueva versión de la clave que se obtuvo en el paso anterior.
    • ORGANIZATION: Es el nombre de tu organización.

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

    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 CA raíz de agregación.
    • AGGREGATION_CA_POOL_NAME: Es el nombre del grupo de CA de agregación.
    • AGGREGATION_CA_KEY_PATH: Es el nombre completo del recurso de la nueva versión de la clave que se muestra en el resultado del paso anterior.

  5. Obtén el nombre completo del recurso de la nueva versión de la clave de la CA 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 este:

    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 CA 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 nueva versión de la clave que se muestra en el resultado del paso anterior.

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

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

  8. Crea una nueva CA raíz de par de etcd en el grupo de CA 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 CA raíz de par de etcd.
    • ETCD_PEER_CA_POOL_NAME: Es el nombre del grupo de AC de pares de etcd.
    • ETCD_PEER_CA_KEY_PATH: Es el nombre completo del recurso de la nueva versión de la clave que se muestra en el resultado del paso anterior.

  9. Antes de continuar, propaga los cambios de la CA 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 del 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 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

    Reemplaza ORIGINAL_CLUSTER_ROOT_CA por el nombre de la CA raíz del clúster original que deseas 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

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

  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 del 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 del par de etcd original que rotas.

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

Después de varios días en los que el clúster permanece en buen estado, 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 CA raíz originales. Antes de seguir estos pasos, verifica lo siguiente:

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

Para borrar las entidades de certificación 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 deseas rotar.

  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 deseas rotar.

  3. Borra la AC 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 del 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 del par de etcd original que rotas.

  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 CA raíz originales se quitarán durante la próxima actualización de la versión del plano de control y del nodo.

Reinicia el plano de control y los nodos

Cuando realices cambios en la configuración de la CA raíz de tu clúster, como habilitar o inhabilitar CAs raíz, o revocar certificados, deberás 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 usa.

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

  3. Solo para la rotación de la CA 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.

    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

Si realizaste los pasos de esta sección durante una rotación de CA, continúa con la siguiente fase de la rotación, que es una de las siguientes secciones de esta página:

¿Qué sigue?