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

Autopilot estándar

---

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

En esta página, se muestra cómo configurar el plano de control de tu clúster de Google Kubernetes Engine (GKE) con autoridades de certificación (CA) y claves que tú administras. Esta guía está dirigida a los administradores de seguridad que tienen requisitos específicos de cumplimiento o políticas organizacionales para controlar la emisión y firma de credenciales.

En esta página, se describe una parte de un conjunto de funciones opcionales del plano de control en GKE que te permiten realizar tareas como verificar la postura de seguridad del plano de control o configurar la encriptación y la firma de credenciales en el plano de control con claves que administras. Para obtener más detalles, consulta Acerca de la autoridad del plano de control de GKE.

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

Ya debes conocer los siguientes conceptos:

• Solicitudes de firma de certificado (CSR)
• Autoridades certificadoras (CA)
• etcd
• Arquitectura del clúster de GKE

Componentes de credenciales del plano de control

Los clústeres de GKE usan CA 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 AC en Certificate Authority Service (servicio de AC), y configurar tus clústeres para que usen estos recursos en lugar de las AC y las claves administradas por Google Cloud.

Para obtener más información sobre los componentes específicos que creas, consulta CA y claves autoadministradas.

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

La autoridad del plano de control de GKE proporciona las siguientes funciones relacionadas con las claves autoadministradas:

• Ejecuta tus propias autoridades certificadoras (CA) y claves (esta página)
• Encripta los componentes del plano de control

Nota: Solo puedes habilitar estas funciones cuando creas un clúster de GKE nuevo. No puedes actualizar los clústeres existentes para usar estas funciones. Para usar ambas funciones en el mismo clúster, realiza todos los procedimientos de configuración de claves y de la CA en ambas guías y, luego, ejecuta el comando de creación del clúster que habilita ambos conjuntos de funciones, como se describe en la sección Crea un clúster.

Objetivos

• Crea claves en Cloud KMS
• Crea CAs en el Servicio de CA
• Otorga roles de Identity and Access Management (IAM) al agente de servicio de GKE
• Crea un clúster de GKE que use tus entidades certificadoras y claves
• Verifica que el clúster use tus entidades certificadoras y claves

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

• GKE
• Cloud KMS
• CA Service
• Cloud Logging

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.

Es posible que los usuarios de Google Cloud nuevos cumplan con los requisitos para acceder a una prueba gratuita.

Cuando completes las tareas que se describen en este documento, podrás borrar los recursos que creaste para evitar que se te siga facturando. Para obtener más información, consulta Realiza una limpieza.

Antes de comenzar

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 instalaste gcloud CLI, asegúrate de que tienes la versión más reciente ejecutando gcloud components update.

Si usas un proveedor de identidad externo (IdP), primero debes acceder a gcloud CLI 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:

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

Install the Google Cloud CLI.

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

Si usas un proveedor de identidad externo (IdP), primero debes acceder a gcloud CLI 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:

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

1. Asegúrate de que tu entorno sea apto para usar las funciones de la autoridad del plano de control de GKE. Para habilitar estas funciones, comunícate con tu equipo de ventas de Google Cloud .
2. Para hacer un seguimiento confiable de la emisión y el uso de credenciales, asegúrate de 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 ejecutar tus propias AC y claves, pídele a tu administrador que te otorgue los siguientes roles de IAM:

• Crear claves de Cloud KMS: Administrador de Cloud KMS (roles/cloudkms.admin) en tu proyecto de claves
• Crea grupos de CA y CA raíz: Administrador del servicio de CA (roles/privateca.admin) en tu proyecto de claves
• Crea clústeres de GKE: 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 a través de roles personalizados o cualquier otro rol predefinido.

Requisitos

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

Limitaciones

Se aplica la siguiente limitación:

• Solo puedes usar claves de Cloud KMS. No puedes usar otro proveedor de KMS ni otro proveedor de encriptación.
• No se admiten las claves de Cloud External Key Manager (Cloud EKM).
• Solo puedes usar las CAs del servicio de CA.

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

  • Para encriptar los discos de arranque del plano de control con una clave de encriptación administrada por el cliente, tu 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 Confidential GKE Nodes 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 ubicación de Google Cloud .

Prepare el entorno

En esta sección, identificarás los Google Cloud proyectos que usarás en este instructivo y crearás un llavero de claves en Cloud KMS para guardar tus claves.

Identifica proyectos

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

• Proyecto de claves: Contiene todas las claves y las CA.
• Proyecto del clúster: Contiene tus clústeres de GKE.

De manera opcional, puedes usar el mismo proyecto para tus claves, AC y clústeres de GKE, pero te recomendamos que uses proyectos separados para que los equipos que administran las operaciones criptográficas en tu organización estén separados de los equipos que administran las operaciones de clústeres.

Crea un llavero de claves

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

Nota: No puedes borrar un llavero de claves después de crearlo. Los llaveros de claves no generan costos adicionales. Sin embargo, tener demasiados llaveros de claves en un proyecto podría hacer que la administración de tus 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

Reemplaza lo siguiente:

• KEY_RING_NAME: Es el nombre del llavero de claves.
• KEY_PROJECT_ID: Es el ID del proyecto de claves.
• LOCATION: Es la región de Google Cloud en la que deseas crear el llavero de claves. Debe ser la misma región en la que se encuentra tu clúster de GKE.

Crea claves

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

Precaución: No habilites la rotación automática de claves con Cloud KMS. La rotación de tus claves de encriptación requiere pasos adicionales para garantizar que los recursos de tu plano de control se vuelvan a encriptar con versiones de claves nuevas antes de que se destruyan las versiones de claves originales.

Ten en cuenta lo siguiente cuando crees estos recursos en Cloud KMS:

• Si tienes un llavero de claves existente en tu proyecto de clave, puedes usarlo para almacenar todas las claves que crees para usar con tu clúster.
• El llavero 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 el propósito de la clave.
• Usa los siguientes algoritmos según el tipo de clave:
  • Claves de firma de ServiceAccount: Un algoritmo PKCS1 de firma RSA sólido, como rsa-sign-pkcs1-4096-sha256 o rsa-sign-pkcs1-3072-sha256.
  • Claves de la autoridad certificadora: Un algoritmo sólido, como ec-sign-p256-sha256
• Se admiten las claves de hardware de Cloud HSM, pero el nivel de protección software es suficiente para la mayoría de los casos de uso. Para obtener detalles sobre las claves de hardware, consulta Cloud HSM.
• No modifiques la duración predeterminada para la destrucción de claves.
• GKE no te impide borrar las claves de Cloud KMS, incluidas las claves de CA Service, que usa el clúster. Antes de borrar claves o entidades certificadoras, asegúrate de que los recursos no se usen.

Para crear tus claves, ejecuta los siguientes comandos:

1. Crea la clave de firma de ServiceAccount de Kubernetes, que también especificas como la 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
   

   Reemplaza KEY_PROJECT_ID por el ID del proyecto de tu proyecto de claves dedicadas.

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 la CA raíz del 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
   

Crea las AC

Después de crear las claves para cada una de las funciones del plano de control, usa cada clave para crear los grupos de CA y las CA raíz correspondientes con CA Service:

1. Crea el grupo de CA 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 estos parámetros, se publicarán los certificados en un bucket de Cloud Storage. Para obtener más información, consulta Habilita la publicación de certificados de CA y CRL para las CA en un grupo de CA.

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
   

   Reemplaza ORGANIZATION por el nombre de tu organización.

3. Crea el grupo de CA de intercambio de tráfico 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 CA raíz del 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 AC de la API de 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 CA 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
   

Otorga roles de IAM al agente de servicio de GKE

El agente de servicio de GKE requiere acceso a los recursos que creaste en Cloud KMS y en CA Service. El agente de servicio usa estos recursos para firmar, verificar y emitir credenciales en el clúster. Puedes usar los siguientes roles predefinidos de IAM:

• Usuario de claves criptográficas de KMS de Kubernetes Engine (roles/container.cloudKmsKeyUser)
• Administrador de certificados del Servicio de CA (roles/privateca.certificateManager)

Para otorgar 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)'
   

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

2. Otorga el rol de usuario de clave criptográfica de KMS de Kubernetes Engine en la clave de firma de la cuenta de servicio que creaste en Crea 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
   

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

3. Otorga el rol de administrador de certificados del servicio de CA en los grupos de CA que creaste en Crea las CA:

   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
   

Otorga roles adicionales cuando no uses gcloud CLI

En esta sección, se describen los pasos de configuración adicionales que debes realizar si planeas configurar tus entidades de certificación y claves con un cliente como Terraform o la consola de Google Cloud en lugar de usar gcloud CLI. Si usas gcloud CLI, omite esta sección y ve a la sección Configura AC y claves en un clúster nuevo.

Cuando usas gcloud CLI para configurar tus AC y claves, como se describe en esta página, gcloud CLI crea y configura automáticamente un agente de servicio para el servicio de AC y le otorga roles de IAM. Sin embargo, si usas un cliente como Terraform o la consola de Google Cloud para configurar tu entorno de Google Cloud, debes realizar estos pasos de configuración de forma manual de la siguiente manera para tu proyecto clave:

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

   Vista previa — triggering service agent creation

   Esta función está sujeta a las “Condiciones de la Oferta de la Fase Previa a la DG” en la sección Condiciones del Servicio Generales de las Condiciones Específicas del Servicio. Las funciones de la fase previa a la DG están disponibles “tal cual” y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa 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 clave:

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

3. Otorga el rol de Visualizador (roles/viewer) y el rol de firmante/verificador de CryptoKey de Cloud KMS (roles/cloudkms.signerVerifier) en todas las claves de la CA raíz que creaste en la sección Crea 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
   

   Reemplaza KEY_PROJECT_NUMBER por el número del proyecto clave del resultado del paso anterior.

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

Configura las CAs y las claves en un clúster nuevo

Advertencia: Borrar claves o entidades de certificación que usa el clúster puede provocar que este sea irrecuperable. Antes de borrar claves o entidades de certificación, asegúrate de que tu clúster ya no use los recursos.

Después de crear claves, grupos de CA y CAs raíz, y otorgar roles de IAM al agente de servicio de GKE, crea un clúster nuevo que use estos recursos.

Los parámetros que especificas en el comando de creación del clúster requieren las siguientes rutas de acceso de recursos como valores:

• Es la ruta de acceso a una versión de clave en Cloud KMS para la clave de firma de la cuenta de servicio que creaste en Crea claves. Especifica esta ruta de acceso para la marca service-account-signing-keys y para la marca service-account-verification-keys.
• Es la ruta de acceso a cada uno de los grupos de CA que creaste en Crea las CA.

Nota: Antes de realizar estos pasos, decide si también deseas encriptar los discos de arranque del plano de control y los discos de etcd con claves que administres. Si lo haces, realiza todos los pasos de configuración de claves en Encripta 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 del clúster en esta sección.

Para configurar un clúster nuevo para que use tus claves y entidades certificadoras, sigue estos pasos:

1. Sigue estos pasos para encontrar la ruta de acceso 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
   

   Reemplaza KEY_PROJECT_ID por el ID del proyecto de la clave.

   El resultado es similar a este:

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

2. Busca las rutas de acceso a cada uno de los grupos de CA que creaste:

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

   El resultado es similar a este:

   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 CA que creaste para GKE.

Crea un clúster

En esta sección, crearás un clúster con diferentes opciones especificadas según las funciones de la autoridad del plano de control de GKE que desees 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 AA y las claves que creaste en este instructivo, 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
  

  Reemplaza lo siguiente:

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

• Para configurar las AA y las claves, así como la encriptación del disco de arranque del plano de control y la encriptación de etcd, haz lo siguiente:

  1. Realiza todos los pasos de configuración de claves en Encripta los discos de arranque de etcd y del plano de control.
  2. Para encontrar las rutas de acceso a cada una de las claves, sigue las instrucciones que se indican en Usa claves de encriptación en un clúster.

  3. Crea un clúster:

     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
     

     Reemplaza lo siguiente:

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

  También puedes usar estas marcas cuando creas un clúster nuevo en modo estándar.

Verifica que el clúster use las claves y las CA que especificaste

En esta sección, se muestra cómo verificar las claves y las entidades certificadoras que se usaron durante la creación del clúster. Puedes realizar esta verificación con Cloud Logging o con Google Cloud CLI.

Usa el registro para verificar las claves y las entidades certificadoras

Para verificar las claves y las entidades certificadoras con Logging, haz lo siguiente:

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

   Ir al 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 entidades certificadoras que administras.

3. Haz clic en Ejecutar consulta.

En los resultados, expande el registro de creación del clúster. Verifica que las rutas de acceso a las claves y las entidades de certificación sean las mismas que las que creaste 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"
  ]
}

Usa gcloud CLI para verificar las claves y las entidades de certificación

Para verificar que el clúster use las AA y las claves que creaste, 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

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Borra los proyectos

Precaución: Borrar un proyecto tiene las siguientes consecuencias:

• Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los IDs personalizados de los proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URLs que usan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto, en lugar de todo el proyecto.

Si planeas explorar varios instructivos, arquitecturas o guías de inicio rápido, reutilizar proyectos puede ser útil para no exceder los límites de cuota de los proyectos.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Borra los recursos individuales

1. Borra el clúster:

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

2. Inhabilita las AC 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. Borra las CA 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. Borra los grupos de CA:

   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. Borra las llaves:

   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 borrar llaveros de Cloud KMS. Sin embargo, los llaveros de claves no generan costos adicionales.

¿Qué sigue?

• Realiza un seguimiento del uso de la identidad desde el momento de la emisión
• Rota las entidades certificadoras y las claves de firma de la cuenta de servicio
• Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.