Ejecutar tus propias autoridades de certificación y claves en GKE

Autopilot Standard

---

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 cómo configurar el plano de control de tu clúster de Google Kubernetes Engine (GKE) con autoridades de certificación (CAs) y claves que tú gestionas. Estas directrices están dirigidas a los administradores de seguridad que tengan requisitos de cumplimiento o de políticas específicos de la organización para controlar la emisión y la firma de credenciales.

En esta página se describe una parte de un conjunto de funciones opcionales del plano de control de GKE que te permiten realizar tareas como verificar el estado de seguridad del plano de control o configurar el cifrado y la firma de credenciales en el plano de control mediante claves que tú gestionas. Para obtener más información, consulta el artículo Acerca de la autoridad del plano de control de GKE.

De forma predeterminada, Google Cloud aplica varias medidas de seguridad al plano de control gestionado. En esta página se describen las funciones opcionales que le ofrecen más visibilidad o control sobre el plano de control de GKE.

Ya deberías conocer los siguientes conceptos:

• Solicitudes de firma de certificados (CSRs)
• Autoridades de certificación (CAs)
• etcd
• Arquitectura de clústeres de GKE

Componentes de credenciales del plano de control

Los clústeres de GKE usan CAs y claves específicas para emitir credenciales en el clúster, como certificados X.509 o tokens de ServiceAccount. Puedes crear claves en Cloud Key Management Service (Cloud KMS) y autoridades de certificación en Servicio de Autoridades de Certificación (CA Service) y configurar tus clústeres para que usen estos recursos en lugar de las autoridades de certificación y las claves gestionadas por Google Cloud.

Para obtener más información sobre los componentes específicos que creas, consulta Autoridades de certificación y claves autogestionadas.

Uso con otras funciones de autoridad del plano de control de GKE

La autoridad del plano de control de GKE ofrece las siguientes funciones relacionadas con las claves autogestionadas:

• Gestionar tus propias autoridades de certificación (CAs) y claves (esta página)
• Cifrar componentes del plano de control

Nota: Solo puedes habilitar estas funciones cuando creas un clúster de GKE. No puedes actualizar los clústeres que ya tengas para usar estas funciones. Para usar ambas funciones en el mismo clúster, sigue todos los procedimientos de configuración de claves y de la autoridad certificadora que se indican en ambas guías y, a continuación, ejecuta el comando de creación de clúster que habilita ambos conjuntos de funciones, tal como se describe en la sección Crear un clúster.

Objetivos

• Crear claves en Cloud KMS
• Crear ACs en el servicio de ACs
• Conceder roles de Gestión de Identidades y Accesos (IAM) al agente de servicio de GKE
• Crear un clúster de GKE que use tus CAs y claves
• Verifica que el clúster usa tus CAs y claves

Costes

En este documento, se utilizan los siguientes componentes facturables de Google Cloud:

• GKE
• Cloud KMS
• CA Service
• Cloud Logging

Para generar una estimación de costes basada en el uso previsto, utiliza la calculadora de precios.

Los usuarios nuevos Google Cloud pueden disfrutar de una prueba gratuita.

Cuando termines las tareas que se describen en este documento, puedes evitar que se te siga facturando eliminando los recursos que has creado. Para obtener más información, consulta la sección Limpiar.

Antes de empezar

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Install the Google Cloud CLI.

Nota: Si ya has instalado la CLI de gcloud, asegúrate de que tienes la versión más reciente ejecutando gcloud components update.

Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

Para inicializar gcloud CLI, ejecuta el siguiente comando:

gcloud init

Verify that billing is enabled for your Google Cloud project.

Enable the Kubernetes Engine, Certificate Authority Service, and Cloud Key Management Service APIs:

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

gcloud services enable container.googleapis.com privateca.googleapis.com cloudkms.googleapis.com

Install the Google Cloud CLI.

Nota: Si ya has instalado la CLI de gcloud, asegúrate de que tienes la versión más reciente ejecutando gcloud components update.

Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

Para inicializar gcloud CLI, ejecuta el siguiente comando:

gcloud init

Verify that billing is enabled for your Google Cloud project.

Enable the Kubernetes Engine, Certificate Authority Service, and Cloud Key Management Service APIs:

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

gcloud services enable container.googleapis.com privateca.googleapis.com cloudkms.googleapis.com

1. Asegúrate de que tu entorno cumple los requisitos para usar las funciones de autoridad del plano de control de GKE. Para habilitar estas funciones, póngase en contacto con su equipo de ventas. Google Cloud
2. Para hacer un seguimiento fiable de la emisión y el uso de credenciales, asegúrate de que los siguientes registros de auditoría de acceso a 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 ejecutar tus propias autoridades de certificación y claves, pide a tu administrador que te conceda los siguientes roles de gestión de identidades y accesos:

• Crea claves de Cloud KMS: Administrador de Cloud KMS (roles/cloudkms.admin) en tu proyecto de claves.
• Crear grupos de autoridades de certificación y autoridades de certificación raíz: Administrador del Servicio de Autoridades de Certificación (roles/privateca.admin) en tu proyecto de claves
• Crea clústeres de GKE: Administrador de clúster de Kubernetes Engine (roles/container.clusterAdmin) en tu proyecto de 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.

Requisitos

Debes usar la versión 1.31.1-gke.1846000 de GKE o una posterior.

Limitaciones

Se aplican las siguientes limitaciones:

• Solo puedes usar claves de Cloud KMS. No puedes usar otro proveedor de KMS ni otro proveedor de cifrado.
• No se admiten las claves de Cloud External Key Manager (Cloud EKM).
• Solo puedes usar ACs del Servicio de Autoridades de Certificación.

• Las regiones y zonas en las que puedes usar la autoridad del plano de control de GKE dependen de si quieres usar funciones específicas, tal como se indica a continuación:

  • Para encriptar los discos de arranque del plano de control con una clave de encriptado gestionada por el cliente, el clúster debe estar en una de las siguientes regiones:
    • asia-east1
    • asia-northeast1
    • asia-southeast1
    • europe-west1
    • europe-west4
    • us-central1
    • us-east1
    • us-east4
    • us-east5
    • us-south1
    • us-west1
    • us-west3
    • us-west4
  • Para usar nodos de Confidential GKE con la autoridad del plano de control de GKE, tu clúster debe estar en una región que admita el modo Confidencial para Hyperdisk Balanced.

  Si no usas estas funciones, puedes usar la autoridad del plano de control de GKE en cualquier Google Cloud ubicación.

Preparar el entorno

En esta sección, identificará los proyectos que usará en este tutorial y creará un conjunto de claves en Cloud KMS para almacenar sus claves. Google Cloud

Identificar proyectos

Te recomendamos que uses proyectos de Google Cloud independientes de la siguiente manera:

• Proyecto clave: contiene todas las claves y las autoridades de certificación.
• Proyecto de clúster: contiene tus clústeres de GKE.

También puedes usar el mismo proyecto para tus claves, CAs y clústeres de GKE, pero te recomendamos que uses proyectos independientes para que los equipos que gestionan las operaciones criptográficas de tu organización estén separados de los que gestionan las operaciones de los clústeres.

Crear un conjunto de claves

Crea un conjunto de claves en el proyecto de claves para almacenar todas las claves de un clúster específico. Debes crear el conjunto de claves en la misma ubicación que tu clúster de GKE.

Nota: No puedes eliminar un llavero después de crearlo. Los conjuntos de claves no generan costes adicionales. Sin embargo, tener demasiados conjuntos de claves en un proyecto puede hacer que la gestión de los recursos en Cloud KMS sea más tediosa.

Ejecuta el siguiente comando:

gcloud kms keyrings create KEY_RING_NAME \
    --location=LOCATION \
    --project=KEY_PROJECT_ID

Haz los cambios siguientes:

• KEY_RING_NAME: el nombre del conjunto de claves.
• KEY_PROJECT_ID: el ID de proyecto de tu proyecto de clave.
• LOCATION: la Google Cloud región en la que quieres crear el conjunto de claves. Debe ser la misma región en la que se encuentre tu clúster de GKE.

Crear claves

Para cada una de las autoridades de credenciales, como las claves de cuentas de servicio y las autoridades de certificación, crea una clave con Cloud KMS. En esta sección se explica cómo crear las claves que usa GKE para firmar y verificar las credenciales del clúster. Puedes especificar tus propias propiedades para estas claves en función de las necesidades de tu organización. Para obtener más información, consulta la página Crear una clave y la referencia de la API projects.locations.keyRings.cryptoKeys.

Precaución: No habilites la rotación automática de claves con Cloud KMS. Para rotar las claves de cifrado, debes seguir pasos adicionales para asegurarte de que los recursos del plano de control se vuelvan a cifrar con las nuevas versiones de las claves antes de que se destruyan las versiones originales.

Ten en cuenta lo siguiente al crear estos recursos en Cloud KMS:

• Si tienes un conjunto de claves en tu proyecto de claves, puedes usarlo para almacenar todas las claves que crees para usar con tu clúster.
• El conjunto de claves debe estar en la misma Google Cloud ubicación que el clúster para minimizar la latencia.
• Las claves deben especificar asymmetric-signing como finalidad de la clave.
• Usa los siguientes algoritmos en función del tipo de clave:
  • Claves de firma de cuentas de servicio: un algoritmo PKCS1 de firma RSA seguro, como rsa-sign-pkcs1-4096-sha256 o rsa-sign-pkcs1-3072-sha256.
  • Claves de autoridad de certificación: un algoritmo seguro, como ec-sign-p256-sha256.
• Se admiten las claves de hardware de Cloud HSM, pero el softwarenivel de protección es suficiente para la mayoría de los casos prácticos. Para obtener información sobre las llaves de hardware, consulta Cloud HSM.
• No modifiques la duración predeterminada para la eliminación de claves.
• GKE no te impide eliminar claves de Cloud KMS, incluidas las claves de servicio de CA, que esté usando el clúster. Antes de eliminar claves o ACs, asegúrate de que los recursos no se estén usando.

Para crear las claves, ejecuta los siguientes comandos:

1. Crea la clave de firma de la cuenta de servicio de Kubernetes, que también especificarás como clave de verificación de la cuenta de servicio durante la creación del clúster:

   gcloud kms keys create sa-signing-key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --purpose="asymmetric-signing" \
       --protection-level=hsm \
       --default-algorithm=rsa-sign-pkcs1-4096-sha256 \
       --project=KEY_PROJECT_ID
   

   Sustituye KEY_PROJECT_ID por el ID del proyecto de tu clave dedicada.

2. Crea la clave de la CA raíz del clúster:

   gcloud kms keys create cluster-ca-key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --purpose="asymmetric-signing" \
       --protection-level=hsm \
       --default-algorithm=ec-sign-p256-sha256 \
       --project=KEY_PROJECT_ID
   

3. Crea la clave de CA raíz de par de etcd:

   gcloud kms keys create etcd-peer-ca-key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --purpose="asymmetric-signing" \
       --protection-level=hsm \
       --default-algorithm=ec-sign-p256-sha256 \
       --project=KEY_PROJECT_ID
   

4. Crea la clave de CA raíz de la API de etcd:

   gcloud kms keys create etcd-api-ca-key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --purpose="asymmetric-signing" \
       --protection-level=hsm \
       --default-algorithm=ec-sign-p256-sha256 \
       --project=KEY_PROJECT_ID
   

5. Crea la clave de la CA raíz de agregación:

   gcloud kms keys create aggregation-ca-key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --purpose="asymmetric-signing" \
       --protection-level=hsm \
       --default-algorithm=ec-sign-p256-sha256 \
       --project=KEY_PROJECT_ID
   

Crear las autoridades de certificación

Después de crear las claves de cada una de las funciones del plano de control, usa cada clave para crear los grupos de CAs y las CAs raíz correspondientes mediante el servicio de CAs:

1. Crea el grupo de autoridades de certificación del clúster:

   gcloud privateca pools create cluster-ca-pool \
       --location=LOCATION \
       --tier=enterprise \
       --project=KEY_PROJECT_ID \
       --no-publish-crl --no-publish-ca-cert
   

   Las marcas --no-publish-crl y --no-publish-ca-cert son opcionales. Si se omiten estas marcas, los certificados se publicarán en un segmento de Cloud Storage. Para obtener más información, consulta Habilitar la publicación de certificados de CA y CRLs para las CAs de un grupo de CAs.

2. Crea la CA raíz del clúster:

   gcloud privateca roots create cluster-root-ca \
       --pool=cluster-ca-pool \
       --location=LOCATION \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/cluster-ca-key/cryptoKeyVersions/1 \
       --subject="CN=cluster-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID \
       --auto-enable
   

   Sustituye ORGANIZATION por el nombre de tu organización.

3. Crea el grupo de autoridades de certificación de los peers de etcd:

   gcloud privateca pools create etcd-peer-ca-pool \
       --location=LOCATION \
       --tier=enterprise \
       --project=KEY_PROJECT_ID \
       --no-publish-crl --no-publish-ca-cert
   

4. Crea la AC raíz de par de etcd:

   gcloud privateca roots create etcd-peer-root-ca \
       --pool=etcd-peer-ca-pool \
       --location=LOCATION \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/etcd-peer-ca-key/cryptoKeyVersions/1 \
       --subject="CN=etcd-peer-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID \
       --auto-enable
   

5. Crea el grupo de autoridades de certificación de la API etcd:

   gcloud privateca pools create etcd-api-ca-pool \
       --location=LOCATION \
       --tier=enterprise \
       --project=KEY_PROJECT_ID \
       --no-publish-crl --no-publish-ca-cert
   

6. Crea la AC raíz de la API de etcd:

   gcloud privateca roots create etcd-api-root-ca \
       --pool=etcd-api-ca-pool \
       --location=LOCATION \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/etcd-api-ca-key/cryptoKeyVersions/1 \
       --subject="CN=etcd-api-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID \
       --auto-enable
   

7. Crea el grupo de AC de agregación:

   gcloud privateca pools create aggregation-ca-pool \
       --location=LOCATION \
       --tier=enterprise \
       --project=KEY_PROJECT_ID \
       --no-publish-crl --no-publish-ca-cert
   

8. Crea la CA raíz de agregación:

   gcloud privateca roots create aggregation-root-ca \
       --pool=aggregation-ca-pool \
       --location=LOCATION \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/aggregation-ca-key/cryptoKeyVersions/1 \
       --subject="CN=aggregation-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID \
       --auto-enable
   

Conceder roles de IAM al agente de servicio de GKE

El agente de servicio de GKE necesita acceso a los recursos que has creado en Cloud KMS y en el servicio de CA. El agente de servicio usa estos recursos para firmar, verificar y emitir credenciales en el clúster. Puede usar los siguientes roles de gestión de identidades y accesos predefinidos:

• Usuario de clave criptográfica de KMS de Kubernetes Engine (roles/container.cloudKmsKeyUser)
• Administrador de certificados del Servicio de Autoridades de Certificación (roles/privateca.certificateManager)

Para conceder estos roles al agente de servicio de GKE, haz lo siguiente:

1. Busca el número de proyecto de tu proyecto de clúster:

   gcloud projects describe CLUSTER_PROJECT_ID \
       --format='value(projectNumber)'
   

   Sustituye CLUSTER_PROJECT_ID por el ID del proyecto de tu clúster.

2. Asigna el rol de usuario de clave criptográfica de KMS de Kubernetes Engine a la cuenta de servicio de la clave de firma que has creado en Crear claves:

   gcloud kms keys add-iam-policy-binding sa-signing-key \
     --location=LOCATION \
     --keyring=KEY_RING_NAME \
     --member="serviceAccount:[e-mail]" \
     --role=roles/container.cloudKmsKeyUser \
     --project=KEY_PROJECT_ID
   

   Sustituye CLUSTER_PROJECT_NUMBER por el número del proyecto del clúster.

3. Asigna el rol Administrador de certificados del Servicio de Autoridades de Certificación a los grupos de autoridades de certificación que hayas creado en Crear las autoridades de certificación:

   gcloud privateca pools add-iam-policy-binding cluster-ca-pool \
       --location=LOCATION \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools add-iam-policy-binding etcd-peer-ca-pool \
       --location=LOCATION \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools add-iam-policy-binding etcd-api-ca-pool \
       --location=LOCATION \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools add-iam-policy-binding aggregation-ca-pool \
       --location=LOCATION \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   

Otorgar roles adicionales cuando no se usa gcloud CLI

En esta sección se describen los pasos de configuración adicionales que debe seguir si tiene previsto configurar sus CAs y claves mediante un cliente como Terraform o la consola de Google Cloud en lugar de usar la CLI de gcloud. Si usas la CLI de gcloud, salta esta sección y ve a la sección Configurar CAs y claves en un clúster nuevo.

Cuando usas la CLI de gcloud para configurar tus ACs y claves, tal como se describe en esta página, la CLI de gcloud crea y configura automáticamente un agente de servicio para el servicio de ACs y le asigna roles de gestión de identidades y accesos. Sin embargo, si usas un cliente como Terraform o la consola Google Cloud para configurar tu entorno Google Cloud, debes seguir estos pasos de configuración manualmente para tu proyecto de clave:

1. Activa la creación del agente de servicio del servicio de CA.

   Vista previa — triggering service agent creation

   Esta función está sujeta a los "Términos de las Ofertas de Acceso Previo a la Disponibilidad General" de la sección Términos Generales de los Servicios de los Términos Específicos de los Servicios. Las funciones previas a la disponibilidad general están disponibles tal cual y pueden tener una compatibilidad y asistencia limitadas. Para obtener más información, consulta las descripciones de las fases de lanzamiento.

   gcloud beta services identity create --service=privateca.googleapis.com \
       --project=KEY_PROJECT_ID
   

2. Busca el número de proyecto de tu proyecto de clave:

   gcloud projects describe KEY_PROJECT_ID \
       --format='value(projectNumber)'
   

3. Asigna el rol Lector (roles/viewer) y el rol Firmante/Verificador de CryptoKey de Cloud KMS (roles/cloudkms.signerVerifier) a todas las claves de CA raíz que hayas creado en la sección Crear claves:

   for key in cluster-ca-key etcd-peer-ca-key etcd-api-ca-key aggregation-ca-key
   do
   gcloud kms keys add-iam-policy-binding $key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --role=roles/viewer \
       --member="serviceAccount:[e-mail]" \
       --project=KEY_PROJECT_ID
   
   gcloud kms keys add-iam-policy-binding $key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --role=roles/cloudkms.signerVerifier \
       --member="serviceAccount:[e-mail]" \
       --project=KEY_PROJECT_ID
   done
   

   Sustituye KEY_PROJECT_NUMBER por el número del proyecto de la clave de la salida del paso anterior.

   Este comando es un bucle for que itera a través de las claves de la CA raíz y otorga a cada rol de esa clave al agente de servicio de CA Service. Si has usado nombres diferentes para las claves de la CA raíz, ejecuta estos comandos manualmente para cada clave.

Configurar CAs y claves en un clúster nuevo

Advertencia: Si eliminas claves o CAs que esté usando el clúster, es posible que los clústeres no se puedan recuperar. Antes de eliminar claves o ACs, asegúrate de que tu clúster ya no utilice los recursos.

Después de crear claves, grupos de ACs y ACs raíz, y de asignar roles de gestión de identidades y accesos al agente de servicio de GKE, crea un clúster que use estos recursos.

Las marcas que especifiques en el comando de creación de clústeres requieren las siguientes rutas de recursos como valores:

• Ruta a una versión de clave de Cloud KMS para la clave de firma de la cuenta de servicio que has creado en Crear claves. Puedes especificar esta ruta para las marcas service-account-signing-keys y service-account-verification-keys.
• Ruta a cada uno de los grupos de autoridades de certificación que ha creado en Crear las autoridades de certificación.

Nota: Antes de seguir estos pasos, decide si también quieres cifrar los discos de arranque del plano de control y los discos de etcd con claves que gestiones. Si lo haces, sigue todos los pasos de configuración clave que se indican en Cifrar los discos de arranque de etcd y del plano de control y especifica las marcas opcionales que se describen en el comando de creación de clústeres de esta sección.

Para configurar un nuevo clúster de forma que use tus claves y CAs, sigue estos pasos:

1. Busca la ruta a la versión más reciente de la clave de firma de la cuenta de servicio habilitada:

   gcloud kms keys versions list \
       --key=sa-signing-key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --project=KEY_PROJECT_ID \
       --filter="STATE=ENABLED" --sort-by=~ --format="value(name)" | sed 1q
   

   Sustituye KEY_PROJECT_ID por el ID del proyecto de la clave.

   El resultado debería ser similar al siguiente:

   projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1
   

2. Busca las rutas de cada uno de los grupos de autoridades de certificación que has creado:

   gcloud privateca pools list --format="get(name)" \
       --project=KEY_PROJECT_ID
   

   El resultado debería ser similar al siguiente:

   projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool
   projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool
   projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool
   projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool
   

   Asegúrate de que el resultado contenga todos los grupos de AC que hayas creado para GKE.

Crear un clúster

En esta sección, creará un clúster con diferentes opciones especificadas en función de las funciones de autoridad del plano de control de GKE que quiera configurar. Solo puedes configurar estas funciones en un clúster durante la creación del clúster. Los siguientes comandos crean clústeres en modo estándar. Para crear clústeres en modo Autopilot, usa las mismas marcas con el comando gcloud container clusters create-auto.

• Para configurar solo las autoridades de certificación y las claves que has creado en este tutorial, ejecuta el siguiente comando:

  gcloud container clusters create example-cluster \
      --location=LOCATION \
      --project=CLUSTER_PROJECT_ID \
      --cluster-version=VERSION \
      --service-account-signing-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
      --service-account-verification-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
      --cluster-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool \
      --etcd-peer-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool \
      --etcd-api-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool \
      --aggregation-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool
  

  Haz los cambios siguientes:

  • CLUSTER_PROJECT_ID: el ID de proyecto del clúster proyecto.
  • VERSION: la versión de GKE del clúster. Debe ser 1.31.1-gke.1846000 o una versión posterior.

• Para configurar las autoridades de certificación y las claves, así como el cifrado del disco de arranque del plano de control y el cifrado de etcd, haz lo siguiente:

  1. Sigue todos los pasos de configuración de claves que se indican en Cifrar los discos de arranque de etcd y del plano de control.
  2. Para encontrar las rutas de cada una de las claves, sigue las instrucciones que se indican en Usar claves de cifrado en un clúster.

  3. Para crear un clúster, sigue estos pasos:

     gcloud container clusters create example-cluster \
         --location=LOCATION \
         --project=CLUSTER_PROJECT_ID \
         --cluster-version=VERSION \
         --service-account-signing-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
         --service-account-verification-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
         --cluster-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool \
         --etcd-peer-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool \
         --etcd-api-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool \
         --aggregation-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool \
         --control-plane-disk-encryption-key=PATH_TO_DISK_KEY \
         --gkeops-etcd-backup-encryption-key=PATH_TO_ETCD_BACKUP_KEY
     

     Haz los cambios siguientes:

     • CLUSTER_PROJECT_ID: el ID del proyecto del clúster.
     • VERSION: la versión de GKE del clúster. Debe ser 1.31.1-gke.1846000 o una versión posterior.
     • PATH_TO_DISK_KEY: la ruta a la clave de cifrado de tu disco.
     • PATH_TO_ETCD_BACKUP_KEY: la ruta a tu clave de cifrado de copia de seguridad interna de etcd.

  También puedes usar estas marcas al crear un clúster en modo estándar.

Verifica que el clúster usa las claves y las autoridades de certificación que has especificado

En esta sección se explica cómo verificar las claves y las autoridades de certificación que se usaron durante la creación del clúster. Puedes realizar esta verificación con Cloud Logging o con la CLI de Google Cloud.

Usar Logging para verificar claves y CAs

Para verificar las claves y las autoridades certificadoras mediante Logging, haz lo siguiente:

1. En la Google Cloud consola, ve a la página Explorador de registros:

   Ir a Explorador de registros

2. Especifica la siguiente consulta:

   resource.type="gke_cluster"
   resource.labels.cluster_name="CLUSTER_NAME"
   resource.labels.location="CLUSTER_LOCATION"
   protoPayload.serviceName="container.googleapis.com"
   protoPayload.methodName=~"google.container.v(1|1alpha1|1beta1).ClusterManager.CreateCluster"
   protoPayload.request.cluster.userManagedKeysConfig:*
   

   protoPayload.request.cluster.userManagedKeysConfig:* filtra los resultados de los registros de creación de clústeres que incluyen claves y CAs que gestionas.

3. Haz clic en Realizar una consulta.

En los resultados, despliega el registro de creación del clúster. Verifica que las rutas a las claves y a las autoridades de certificación sean las mismas que las que has creado para ese clúster, como en el siguiente ejemplo:

# lines omitted for clarity
userManagedKeysConfig: {
  aggregationCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool"
  clusterCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool"
  etcdApiCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool"
  etcdPeerCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool"
  serviceAccountSigningKeys: [
    0: "projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1"
  ]
  serviceAccountVerificationKeys: [
    0: "projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1"
  ]
}

Usar la CLI de gcloud para verificar claves y CAs

Para verificar que el clúster usa las CAs y las claves que has creado, ejecuta el siguiente comando:

gcloud container clusters describe example-cluster \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID

El resultado debe incluir el campo userManagedKeysConfig, como en el siguiente ejemplo:

# lines omitted for clarity
userManagedKeysConfig:
  sa-signing-key: projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1
  sa-verification-key: projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1
  cluster-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool
  etcd-peer-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool
  etcd-api-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool
  aggregation-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool

Limpieza

Para evitar que los recursos utilizados en este tutorial se cobren en tu cuenta de Google Cloud, elimina el proyecto que contiene los recursos o conserva el proyecto y elimina los recursos.

Eliminar los proyectos

Precaución: Eliminar un proyecto tiene los siguientes efectos:

• Se elimina todo el contenido del proyecto. Si has usado un proyecto que ya existía para las tareas de este documento, cuando lo elimines, también se eliminará cualquier otro trabajo que hayas realizado en él.
• Se pierden los IDs de proyecto personalizados. Cuando creaste este proyecto, es posible que hayas creado un ID de proyecto personalizado que quieras usar en el futuro. Para conservar las URLs que usan el ID del proyecto, como una URL appspot.com, elimina los recursos seleccionados dentro del proyecto en lugar de eliminar todo el proyecto.

Si tienes previsto consultar varias arquitecturas, tutoriales o guías de inicio rápido, reutilizar los proyectos puede ayudarte a no superar los límites de cuota de proyectos.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Eliminar recursos concretos

1. Elimina el clúster:

   gcloud container clusters delete example-cluster \
       --location=LOCATION \
       --project=CLUSTER_PROJECT_ID
   

2. Inhabilita las CAs raíz:

   gcloud privateca roots disable cluster-root-ca \
       --location=LOCATION \
       --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots disable etcd-peer-root-ca \
       --location=LOCATION \
       --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots disable etcd-api-root-ca \
       --location=LOCATION \
       --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots disable aggregation-root-ca \
       --location=LOCATION \
       --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool \
       --project=KEY_PROJECT_ID
   

3. Elimina las CAs raíz:

   gcloud privateca roots delete cluster-root-ca \
       --location=LOCATION \
       --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots delete etcd-peer-root-ca \
       --location=LOCATION \
       --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots delete etcd-api-root-ca \
       --location=LOCATION \
       --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool \
       --project=KEY_PROJECT_ID
   
   gcloud privateca roots delete aggregation-root-ca \
       --location=LOCATION \
       --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool \
       --project=KEY_PROJECT_ID
   

4. Elimina los grupos de autoridades de certificación:

   gcloud privateca pools delete cluster-ca-pool --location=LOCATION \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools delete etcd-peer-ca-pool --location=LOCATION \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools delete etcd-api-ca-pool --location=LOCATION \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools delete aggregation-ca-pool --location=LOCATION \
       --project=KEY_PROJECT_ID
   

5. Elimina las teclas:

   gcloud kms keys versions destroy 1 \
       --location=LOCATION \
       --keyring=KEY_RING_NAME \
       --key=sa-signing-key \
       --project=KEY_PROJECT_ID
   
   gcloud kms keys versions destroy 1 \
       --location=LOCATION \
       --keyring=KEY_RING_NAME \
       --key=cluster-ca-key \
       --project=KEY_PROJECT_ID
   
   gcloud kms keys versions destroy 1 \
       --location=LOCATION \
       --keyring=KEY_RING_NAME \
       --key=etcd-peer-ca-key \
       --project=KEY_PROJECT_ID
   
   gcloud kms keys versions destroy 1 \
       --location=LOCATION \
       --keyring=KEY_RING_NAME \
       --key=etcd-api-ca-key \
       --project=KEY_PROJECT_ID
   
   gcloud kms keys versions destroy 1 \
       --location=LOCATION \
       --keyring=KEY_RING_NAME \
       --key=aggregation-ca-key \
       --project=KEY_PROJECT_ID
   

No puedes eliminar conjuntos de claves de Cloud KMS. Sin embargo, los llaveros no conllevan costes adicionales.

Siguientes pasos

• Monitorizar el uso de la identidad desde el momento de la emisión
• Rota las CAs y las claves de firma de la cuenta de servicio
• Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.