Usa el complemento de Secret Manager con Google Kubernetes Engine

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. Instalar el complemento de Secret Manager en un clúster de GKE nuevo o existente.
  2. Configurar aplicaciones para autenticarse en la API de Secret Manager
  3. Define qué Secrets se activarán en los Pods de Kubernetes con un archivo YAML SecretProviderClass.
  4. Crea un volumen en el que se activarán los secretos. Después de adjuntar el volumen, las aplicaciones del contenedor pueden acceder a los datos en su sistema de archivos.

El complemento de Secret Manager se deriva del controlador de CSI de Secret Store de Kubernetes de código abierto y el 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.

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 tienes que escribir 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 de forma selectiva a los secretos desde los Pods de GKE con el complemento de Secret Manager. De esta manera, puedes usar las funciones que ofrece Secret Manager, como la encriptación con 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 pasar 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 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 de Secret Store de código abierto:

Antes de comenzar

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

    Habilita las API

  • Si quieres usar Google Cloud CLI para esta tarea, instala y, luego, initialize la gcloud CLI. Si instalaste antes gcloud CLId, obtén la versión más reciente mediante la ejecución del comando gcloud components update.

  • Asegúrate de que el clúster ejecute la versión de GKE 1.29 o 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 los 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 cuando creas un 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 de GKE o una posterior. Si el canal de versiones predeterminado no incluye esta versión, usa la marca --release-channel para elegir uno que sí lo haga.
    • PROJECT_ID: El ID del proyecto de Google Cloud.

Clúster de Autopilot

  • Para habilitar el complemento de Secret Manager en un clúster nuevo de Autopilot, 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 de GKE o una posterior. Si el canal de versiones predeterminado no incluye esta versión, usa la marca --release-channel para elegir un canal de versiones que lo haga.
    • 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 los volúmenes de Kubernetes con el controlador y el nombre del 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 identidad de las cargas de trabajo del Pod en el que se activa un Secret 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:

  • Usa una política de Identity and Access Management (IAM) para vincular una cuenta de servicio de IAM a una Cuenta de servicio de Kubernetes. Puedes crear una nueva ServiceAccount de Kubernetes o usar una existente en cualquier espacio de nombres, incluida la predeterminada de Kubernetes ServiceAccount.
  • Usa las vinculaciones de IAM para otorgar a la cuenta de servicio de IAM acceso a los secretos en Secret Manager.

Los Pods que usan la ServiceAccount de Kubernetes configurada se autentican automáticamente como la cuenta de servicio de IAM cuando acceden a la API de Secret Manager.

Vincular la ServiceAccount de Kubernetes a la cuenta de servicio de IAM

Para permitir que la cuenta de servicio de Kubernetes actúe en nombre de la cuenta de servicio de IAM, agrega una vinculación de política de IAM entre las dos cuentas de servicio.

Usa una ServiceAccount de Kubernetes nueva

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

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: KSA_NAME
      namespace: NAMESPACE
      annotations:
        iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
    

    Reemplaza lo siguiente:

    • KSA_NAME: Es el nombre de la cuenta de servicio de Kubernetes nueva.
    • NAMESPACE: Es el nombre del espacio de nombres de Kubernetes para la cuenta de servicio.
    • GSA_NAME: Es el nombre de la cuenta de servicio de IAM.
    • PROJECT_ID: Es el ID del proyecto de Google Cloud para tu cuenta de servicio de IAM.
  2. Aplica el manifiesto

    kubectl apply -f service-account.yaml
    
  3. Para vincular la cuenta de servicio de IAM a una cuenta de servicio de Kubernetes nueva, ejecuta el siguiente comando:

    gcloud iam service-accounts add-iam-policy-binding \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" \
        GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
    

Usar una ServiceAccount de Kubernetes existente

Para vincular la cuenta de servicio de IAM a una ServiceAccount de Kubernetes existente, ejecuta el siguiente comando:

gcloud iam service-accounts add-iam-policy-binding \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" \
    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

Reemplaza lo siguiente:

  • KSA_NAME: Es el nombre de tu ServiceAccount de Kubernetes existente.
  • NAMESPACE: Es el nombre del espacio de nombres de Kubernetes para la cuenta de servicio.
  • GSA_NAME: Es el nombre de la cuenta de servicio de IAM.
  • PROJECT_ID: Es el ID del proyecto de Google Cloud para tu cuenta de servicio de IAM.

Otorga permiso a la cuenta de servicio de IAM para acceder al Secret

Si quieres otorgar permiso a la cuenta de servicio para acceder al secreto, ejecuta el siguiente comando:

gcloud secrets add-iam-policy-binding SECRET_NAME \
    --member=serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/secretmanager.secretAccessor

Reemplaza lo siguiente:

  • SECRET_NAME: Es el nombre del Secret en Secret Manager.
  • GSA_NAME: Es el nombre de la cuenta de servicio de IAM.
  • PROJECT_ID: Es el ID del proyecto de Google Cloud para tu cuenta de servicio de IAM.

Cómo definir qué secretos activar

Para especificar qué secretos activar como archivos en el Pod de Kubernetes, crea un manifiesto YAML de SecretProviderClass y enumera los secretos que se activarán y el nombre de archivo para activarlos. 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 secreto.
    • 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 el volumen en el que se activarán los secretos

  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 cuenta de servicio 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 existente del almacén de secretos

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

  1. Actualiza el nombre de tu SecretProviderClass y el 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 para tu 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.