Usa el complemento de Secret Manager con Google Kubernetes Engine

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

La integración entre Secret Manager y Google Kubernetes Engine (GKE) te permite almacenar datos sensibles, como contraseñas y certificados que los clústeres de GKE usan como secretos en Secret Manager.

En esta página, se explica cómo puedes usar el complemento de Secret Manager para acceder a los secretos almacenados en Secret Manager como volúmenes activados en los Pods de Kubernetes.

Este proceso implica los siguientes pasos:

1. Instala el complemento de Secret Manager en un clúster de GKE nuevo o existente.
2. Configura las aplicaciones para autenticarte en la API de Secret Manager.
3. Define qué secretos activar en los Pods de Kubernetes con un archivo YAML SecretProviderClass.
4. Crea un volumen en el que se activarán los Secrets. Una vez que se adjunta el volumen, las aplicaciones del contenedor pueden acceder a los datos en el sistema de archivos del contenedor.

El complemento de Secret Manager se deriva del controlador de CSI de Secrets Store de Kubernetes de código abierto y del proveedor de Google Secret Manager. Si usas el controlador de CSI del almacén de secretos de código abierto para acceder a los secretos, puedes migrar al complemento de Secret Manager. Para obtener más información, consulta Migra desde el controlador de CSI del almacén de secretos existente.

Importante: En este documento, se usa el término secreto para hacer referencia a los datos sensibles almacenados en Secret Manager, y no al objeto secreto en la API de GKE.

Ventajas

El complemento de Secret Manager proporciona los siguientes beneficios:

• Puedes usar una solución completamente administrada y compatible para acceder a los secretos de Secret Manager desde GKE sin ninguna sobrecarga operativa.
• No es necesario que escribas un código personalizado para acceder a los secretos almacenados en Secret Manager.
• Puedes almacenar y administrar todos tus secretos de forma centralizada en Secret Manager y acceder a ellos de manera selectiva desde los pods de GKE mediante el complemento de Secret Manager. Si lo haces, puedes usar las funciones que ofrece Secret Manager, como la encriptación de CMEK, el control de acceso detallado, la rotación administrada, la administración del ciclo de vida y los registros de auditoría, junto con las funciones de Kubernetes, como el paso de secretos a contenedores en forma de volúmenes activados.
• El complemento de Secret Manager es compatible con los clústeres Standard y Autopilot.
• El complemento de Secret Manager admite implementaciones de linux/arm64 y linux/amd64.

Limitaciones

Esta versión de Versión preliminar del complemento de Secret Manager no admite las siguientes funciones que están disponibles en el controlador de CSI del almacén de secretos de código abierto:

• Rotación automática de secretos
• Sincronizar como Secret de Kubernetes

Antes de comenzar

• Habilita las API de Secret Manager and Google Kubernetes Engine.

  Habilita las API

• Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, initialize gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente.

  Nota: Para las instalaciones existentes de gcloud CLI, asegúrate de establecer las propiedades compute/region y compute/zone. Cuando configuras ubicaciones predeterminadas, puedes evitar errores en gcloud CLI como los siguientes: One of [--zone, --region, --location] must be supplied: Please specify location.

• Asegúrate de que el clúster ejecute la versión 1.29 de GKE o una posterior con una imagen de nodo de Linux. El complemento de Secret Manager no es compatible con nodos de Windows Server.

Instala el complemento de Secret Manager

Puedes instalar el complemento de Secret Manager en clústeres de Standard y de Autopilot. Asegúrate de que la Federación de identidades para cargas de trabajo para GKE esté habilitada en el clúster estándar. La Federación de identidades para cargas de trabajo para GKE está habilitada de forma predeterminada en un clúster de Autopilot. Los Pods de Kubernetes usan Workload Identity para autenticarse en la API de Secret Manager.

Instala el complemento de Secret Manager en un clúster de GKE nuevo

Para instalar el complemento de Secret Manager durante la creación del clúster, sigue estos pasos:

Clúster estándar

• Para habilitar el complemento de Secret Manager en un clúster estándar nuevo, ejecuta el siguiente comando:

  gcloud beta container clusters create CLUSTER_NAME \
      --enable-secret-manager \
      --location=LOCATION \
      --cluster-version=VERSION \
      --workload-pool=PROJECT_ID.svc.id.goog
  

  Reemplaza lo siguiente:

  • CLUSTER_NAME: es el nombre de tu clúster.
  • LOCATION: Es la región o zona de Compute Engine para el clúster.
  • VERSION: Es la versión de GKE específica que deseas usar. Asegúrate de que el clúster ejecute la versión 1.29 o posterior de GKE. Si el canal de versiones predeterminado no incluye esta versión, usa la marca --release-channel para elegir un canal de versiones que la incluya.
  • PROJECT_ID: El ID del proyecto de Google Cloud.

Clúster de Autopilot

• Para habilitar el complemento de Secret Manager en un clúster de Autopilot nuevo, ejecuta el siguiente comando:

  gcloud beta container clusters create-auto CLUSTER_NAME \
      --enable-secret-manager \
      --cluster-version=VERSION \
      --location=LOCATION
  

  Reemplaza lo siguiente:

  • CLUSTER_NAME: Es el nombre de tu clúster.
  • VERSION: Es la versión de GKE específica que deseas usar. Asegúrate de que el clúster ejecute la versión 1.29 o posterior de GKE. Si el canal de versiones predeterminado no incluye esta versión, usa la marca --release-channel para elegir un canal de versiones que la incluya.
  • LOCATION: Es la región para tu clúster, como us-central1.

Después de habilitar el complemento de Secret Manager, puedes usar el controlador de CSI de Secret Store en volúmenes de Kubernetes con el nombre del controlador y aprovisionador: secrets-store-gke.csi.k8s.io.

Instala el complemento de Secret Manager en un clúster de GKE existente

Para habilitar el complemento de Secret Manager en un clúster existente, ejecuta el siguiente comando:

  gcloud beta container clusters update CLUSTER_NAME \
      --enable-secret-manager \
      --location=LOCATION

Reemplaza lo siguiente:

• CLUSTER_NAME: Es el nombre del clúster existente.
• LOCATION: Es la región del clúster, como us-central1.

Configura aplicaciones para autenticarte en la API de Secret Manager

El proveedor de Google Secret Manager usa la Workload Identity del Pod en el que se activa un secreto cuando se autentica en la API de Secret Manager. Para permitir que tus aplicaciones se autentiquen en la API de Secret Manager con la Federación de identidades para cargas de trabajo para GKE, sigue estos pasos:

• Crea una ServiceAccount de Kubernetes nueva o usa una existente en cualquier espacio de nombres, incluida la predeterminada.

• Crea una política de permisos de Identity and Access Management (IAM) para el secreto en Secret Manager.

Los Pods que usan la ServiceAccount de Kubernetes configurada se autentican de forma automática como el identificador principal de IAM que corresponde a ServiceAccount de Kubernetes cuando se accede a la API de Secret Manager.

Crea una nueva ServiceAccount de Kubernetes

1. Guarda el siguiente manifiesto como service-account.yaml:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: KSA_NAME
     namespace: NAMESPACE
   

   Reemplaza lo siguiente:

   • KSA_NAME: Es el nombre de tu nueva ServiceAccount de Kubernetes.
   • NAMESPACE: Es el nombre del espacio de nombres de Kubernetes para la cuenta de servicio.

2. Aplica el manifiesto

   kubectl apply -f service-account.yaml
   

3. Crea una política de permisos de IAM que haga referencia a la nueva ServiceAccount de Kubernetes y otórgale permiso para acceder al secreto:

   gcloud secrets add-iam-policy-binding SECRET_NAME \
       --role=roles/secretmanager.secretAccessor \
       --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME
   

   Reemplaza lo siguiente:

   • SECRET_NAME: Es el nombre del secreto en Secret Manager.
   • PROJECT_NUMBER: Es el número numérico de proyecto de Google Cloud.
   • PROJECT_ID: Es el ID del proyecto de Google Cloud que contiene el clúster de GKE.
   • NAMESPACE: Es el nombre del espacio de nombres de Kubernetes para la cuenta de servicio.
   • KSA_NAME: Es el nombre de tu ServiceAccount de Kubernetes existente.

Usa una ServiceAccount de Kubernetes existente

Crea una política de permisos de IAM que haga referencia a la ServiceAccount de Kubernetes existente y otórgale permiso para acceder al secreto:

gcloud secrets add-iam-policy-binding SECRET_NAME \
    --role=roles/secretmanager.secretAccessor \
    --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME

Reemplaza lo siguiente:

• SECRET_NAME: Es el nombre del secreto en Secret Manager.
• PROJECT_NUMBER: Es el número numérico de proyecto de Google Cloud.
• PROJECT_ID: Es el ID del proyecto de Google Cloud que contiene el clúster de GKE.
• NAMESPACE: Es el nombre del espacio de nombres de Kubernetes para la cuenta de servicio.
• KSA_NAME: Es el nombre de tu ServiceAccount de Kubernetes existente.

Define qué Secrets se activarán

Para especificar qué secretos activar como archivos en el pod de Kubernetes, crea un manifiesto YAML SecretProviderClass y enumera los secretos que se activarán y el nombre de archivo con el que se activarán. Lleva a cabo los pasos siguientes:

1. Guarda el siguiente manifiesto como app-secrets.yaml:

   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: SECRET_PROVIDER_CLASS_NAME
   spec:
     provider: gke
     parameters:
       secrets: |
         - resourceName: "projects/PROJECT_ID/secrets/SECRET_NAME/versions/SECRET_VERSION"
           path: "FILENAME.txt"
   

   Reemplaza lo siguiente:

   • SECRET_PROVIDER_CLASS_NAME: Es el nombre del objeto SecretProviderClass.
   • PROJECT_ID: El ID de tu proyecto
   • SECRET_NAME: Es el nombre del Secret.
   • SECRET_VERSION: Es la versión del secreto.
   • FILENAME.txt: Es el nombre de archivo en el que se activará el valor del secreto. Puedes crear varios archivos con las variables resourceName y path.

2. Aplica el manifiesto

   kubectl apply -f app-secrets.yaml
   

3. Verifica que se haya creado el objeto SecretProviderClass:

   kubectl get SecretProviderClasses
   

Configura un volumen en el que se activarán los Secrets

1. Guarda la siguiente configuración como my-pod.yaml.

   apiVersion: v1
   kind: Pod
   metadata:
     name: POD_NAME
     namespace: default
   spec:
     serviceAccountName: KSA_NAME
     containers:
     - image: IMAGE_NAME
       imagePullPolicy: IfNotPresent
       name: POD_NAME
       resources:
         requests:
           cpu: 100m
       stdin: true
       stdinOnce: true
       terminationMessagePath: /dev/termination-log
       terminationMessagePolicy: File
       tty: true
       volumeMounts:
         - mountPath: "/var/secrets"
           name: mysecret
     volumes:
     - name: mysecret
       csi:
         driver: secrets-store-gke.csi.k8s.io
         readOnly: true
         volumeAttributes:
           secretProviderClass: SECRET_PROVIDER_CLASS_NAME
   

   Reemplaza lo siguiente:

   • POD_NAME: Es el nombre del Pod de Kubernetes en el que se activa el secreto.
   • KSA_NAME: La ServiceAccount de Kubernetes que configuraste en el paso Configura la cuenta de servicio de Workload Identity
   • IMAGE_NAME: Es el nombre de la imagen del contenedor
   • SECRET_PROVIDER_CLASS_NAME: Es el nombre del objeto SecretProviderClass.

2. Aplica la configuración al clúster.

   kubectl apply -f my-pod.yaml
   

En este paso, se activa un volumen mysecret en /var/secrets mediante el controlador de CSI (secrets-store-gke.csi.k8s.io). Este volumen hace referencia al objeto SecretProviderClass, que actúa como proveedor.

Migra desde el controlador de CSI del almacén de secretos existente

Si migras al complemento de Secret Manager desde tu instalación existente del controlador de CSI del almacén de secretos, actualiza el manifiesto del Pod de la siguiente manera:

1. Actualiza el nombre de tu SecretProviderClass y provider como se describe en el siguiente manifiesto:

   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: app-secrets-gke
   spec:
     provider: gke
     parameters:
       secrets: |
         - resourceName: "projects/<project_id>/secrets/<secret_name>/versions/<secret_version>"
           path: "good1.txt"
   

2. Actualiza driver y secretProviderClass del volumen de Kubernetes como se describe en el siguiente manifiesto:

   volumes:
     - name: mysecret
       csi:
         driver: secrets-store-gke.csi.k8s.io
         readOnly: true
         volumeAttributes:
           secretProviderClass: "app-secrets-gke"
   

Inhabilita el complemento de Secret Manager

Para inhabilitar el complemento de Secret Manager en un clúster estándar existente o en un clúster de Autopilot, ejecuta el siguiente comando:

  gcloud beta container clusters update CLUSTER_NAME \
      --no-enable-secret-manager \
      --region=REGION

Reemplaza lo siguiente:

• CLUSTER_NAME: Es el nombre de tu clúster.
• REGION: Es la región del clúster, como us-central1.