La integración entre Secret Manager y Google Kubernetes Engine (GKE) te permite almacenar datos sensibles, como contraseñas y certificados que usa GKE. como Secrets en Secret Manager.
En esta página, se explica cómo puedes usar el complemento de Secret Manager para acceder a los Secrets almacenados en Secret Manager como volúmenes activados en los Pods de Kubernetes.
Este proceso implica los siguientes pasos:
- Instala el complemento de Secret Manager en un dispositivo nuevo o existente clúster de GKE.
- Configura las aplicaciones para autenticarte en la API de Secret Manager.
- Define qué secretos activar en los Pods de Kubernetes con un archivo YAML
SecretProviderClass
. - Crea un volumen en el que se activarán los Secrets. Después de colocar el volumen, Las aplicaciones en el contenedor pueden acceder a los datos en su sistema de archivos.
El complemento de Secret Manager se deriva del controlador de CSI del almacén de secretos de Kubernetes de código abierto. y el proveedor de Google Secret Manager. Si usas el controlador de CSI del almacén de Secrets de código abierto para acceder a los Secrets, 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.
Beneficios
El complemento de Secret Manager proporciona los siguientes beneficios:
- Puedes usar una solución completamente administrada y compatible para acceder a Secret Manager de Secrets de GKE sin 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 los Secrets de forma selectiva desde los Pods de GKE Complemento de Secret Manager. Al hacer esto, puedes usar las funciones que ofrece Secret Manager, como la encriptación con CMEK, el control la rotación administrada, la administración del ciclo de vida y los registros de auditoría, junto con el uso de 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 de
linux/arm64
ylinux/amd64
.
Limitaciones
Esta versión Preview de Secret Manager este complemento no es compatible con las siguientes funciones que están disponibles en la versión de código abierto Controlador de CSI del almacén de secretos:
Antes de comenzar
-
Habilita las API de Secret Manager and Google Kubernetes Engine.
Si quieres usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si instalada previamente gcloud CLI, ejecuta el siguiente comando para obtener la versión más reciente el comando
gcloud components update
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 Windows Nodos de servidor.
Instala el complemento de Secret Manager
Puedes instalar el complemento de Secret Manager en ambos clústeres de Standard y los clústeres de Autopilot. Asegúrate de que la Federación de identidades para cargas de trabajo para GKE sea habilitado en el clúster Standard. La Federación de identidades para cargas de trabajo para GKE es habilitado 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 en la creación del clúster, haz lo siguiente: sigue estos pasos:
Clúster estándar
Para habilitar el complemento de Secret Manager en una nueva En el clúster estándar, 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
: 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 a la que que quieres usar. Asegúrate de que el clúster ejecute la versión de GKE 1.29 o posterior. Si el valor predeterminado canal de versiones no incluye esta versión, usa la marca--release-channel
para elegir una de versiones canary que sí lo hace.PROJECT_ID
: El ID del proyecto de Google Cloud.
Clúster de Autopilot
Para habilitar el complemento de Secret Manager en un nuevo clúster 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 a la que que quieres usar. Asegúrate de que el clúster ejecute la versión de GKE 1.29 o posterior. Si el canal de versiones predeterminado no incluye esta versión, usa la marca--release-channel
para elegir una de versiones canary que sí lo hace.LOCATION
: Es la región para tu clúster, comous-central1
.
Después de habilitar el complemento de Secret Manager, puedes
puedes usar el controlador de CSI de Secrets Store en 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, haz lo siguiente: 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 tu clúster, comous-central1
.
Configura aplicaciones para autenticarte en la API de Secret Manager
El proveedor de Google Secret Manager usa Workload Identity del Pod en el que se activa un Secret cuando se autentica en el API de Secret Manager. Para permitir que tus aplicaciones se autentiquen en el Para la API de Secret Manager que usa la Federación de identidades para cargas de trabajo para GKE, sigue estos pasos:
Crea una nueva ServiceAccount de Kubernetes. o usar una ServiceAccount existente de Kubernetes en cualquier espacio de nombres, incluido el ServiceAccount predeterminado de Kubernetes.
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 automáticamente como el identificador principal de IAM que corresponde ServiceAccount de Kubernetes cuando accedes a la API de Secret Manager.
Crea una nueva ServiceAccount de Kubernetes
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.
Aplica el manifiesto
kubectl apply -f service-account.yaml
Crear una política de permisos de IAM que haga referencia al nuevo Kubernetes ServiceAccount 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 infraestructura existente ServiceAccount 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é Secrets quieres activar como archivos en el Pod de Kubernetes, crea un
SecretProviderClass
YAML y enumera los secretos para activar y el nombre del archivo en
montarlos Lleva a cabo los pasos siguientes:
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 objetoSecretProviderClass
.PROJECT_ID
: El ID de tu proyectoSECRET_NAME
: Es el nombre del Secret.SECRET_VERSION
: Es la versión del secreto.FILENAME.txt
: Es el nombre del archivo en el que estará el valor del secreto. activa. Puedes crear varios archivos conresourceName
ypath
. variables.
Aplica el manifiesto
kubectl apply -f app-secrets.yaml
Verifica que se haya creado el objeto
SecretProviderClass
:kubectl get SecretProviderClasses
Configura un volumen en el que se activarán los Secrets
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 encuentra el secreto. está activadoKSA_NAME
: La ServiceAccount de Kubernetes que configuraste en el paso Configura la cuenta de servicio de Workload IdentityIMAGE_NAME
: Es el nombre de la imagen del contenedorSECRET_PROVIDER_CLASS_NAME
: Es el nombre del objetoSecretProviderClass
.
Aplica la configuración al clúster.
kubectl apply -f my-pod.yaml
En este paso, se activa un volumen mysecret
en /var/secrets
con el controlador de CSI.
(secrets-store-gke.csi.k8s.io). Este volumen hace referencia al objeto SecretProviderClass
que actúa como el proveedor.
Migra desde el controlador de CSI del almacén de secretos existente
Si migras al complemento de Secret Manager desde tu la instalación existente del controlador de CSI del almacén de secretos actualiza tu manifiesto del Pod de la siguiente manera:
Actualiza el nombre de tu
SecretProviderClass
yprovider
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"
Actualiza el
driver
y elsecretProviderClass
de tu instancia de Kubernetes. volumen, 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 Standard o en un clúster de Autopilot, ejecuta lo siguiente: :
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, comous-central1
.