Mantener los secrets seguros es clave en cualquier despliegue de Kubernetes. Tradicionalmente, gestionarlos en GKE implicaba inyectarlos en los pods como variables de entorno o volúmenes. Aunque funciona, este enfoque resulta engorroso y abre interrogantes de seguridad. Por suerte, Google Cloud ofrece una solución potente: el add-on Secret Manager para GKE.
En este post te explico cómo usar el add-on Secret Manager para GKE para acceder a los secrets almacenados en Secret Manager como volúmenes montados en los Pods de GKE.
:: A mayo de 2024, esta funcionalidad sigue en preview , así que úsala con precaución.
¿Qué es Secret Manager?
Secret Manager es un servicio gestionado dentro de Google Cloud Platform (GCP) pensado para almacenar y recuperar información sensible, como API keys, contraseñas y certificados. Tiene varias ventajas:
- Gestión centralizada: los secrets se guardan en un único lugar, lo que simplifica el control de acceso y la auditoría.
- Mayor seguridad: los secrets se cifran en reposo y en tránsito, lo que reduce el riesgo de exposición.
- Workload Identity simplificada: los workloads acceden a los secrets de forma segura mediante workload identity, sin necesidad de credenciales adicionales.
Conoce el add-on Secret Manager
El add-on Secret Manager para Google Kubernetes Engine (GKE) simplifica la forma de acceder y gestionar secrets en tus pods. Estos son sus beneficios:
- Acceso fácil: sin necesidad de escribir código personalizado, accedes directamente a los secrets almacenados en Secret Manager desde tus pods de GKE.
- Gestión centralizada: almacena y controla todos tus secrets en un solo lugar (Secret Manager) y otorga acceso a secrets específicos a tus pods de GKE.
- Seguridad reforzada: aprovecha funciones de Secret Manager como cifrado, control de acceso, rotación y logs de auditoría, junto con funciones de Kubernetes como el montaje de volúmenes para los secrets.
- Amplia compatibilidad: funciona tanto con clústeres de GKE Standard como Autopilot, y soporta despliegues en arquitecturas AMD y ARM.
El add-on se basa en el proyecto open source Kubernetes Secrets Store CSI Driver y en el Google Secret Manager provider. Si ya usas el Secrets Store CSI Driver open source para acceder a tus secrets, puedes migrar al add-on Secret Manager. Para más información, consulta Migrate from the existing Secrets Store CSI Driver.
Como hoy el add-on aún está en preview, todavía no incluye estas funciones:
¿No conviene usar mejor External Secrets Operator?
En resumen: si necesitas cumplir con alguna normativa de compliance y tienes que evitar secrets nativos de Kubernetes en tu clúster, lo recomendable es usar el Secrets Store CSI driver junto con el GKE Secrets Add-On, porque te permite montar secrets desde Secret Manager directamente como volúmenes en tus pods. Si no tienes esa necesidad, probablemente puedas darle una oportunidad a ESO.
Hay una comparación interesante entre External Secrets Operator y Secrets Store CSI driver que un usuario de GitHub llamado Lucas publicó en este comentario, y que voy a incluir en este artículo:
ESO sincroniza secrets desde un proveedor cloud hacia secrets en k8s, así que puedes seguir usando los secrets de k8s si estás acostumbrado a ello.
SSCSID monta el secret externo como un volumen directamente en un pod, y tener un secret de k8s en el clúster es opcional.
ESO se enfoca en mantener la configuración en el CRD; lo que creas en el secret store del proveedor es solamente el valor del secret en sí.
SSCSID requiere que toda la configuración o el secret se almacene directamente en el proveedor, ya que la aplicación va a consumirlo. Esto puede resultar muy complicado con configuraciones más grandes que tengan algunos secrets embebidos.
Los secrets de ESO se pueden usar de forma nativa con cualquier recurso en k8s, eso es obvio, pero 👇
SSCSID necesita un webhook de pod para funcionar realmente bien. No puedes usar fácilmente los secrets de SSCSID para referenciarlos en un ingress o en un dockerconfig al descargar imágenes, ya que su objetivo es solo montarse en un pod. Incluso si quieres habilitar la sincronización con secrets de k8s, primero tienes que montar el secret en un pod para sincronizarlo.
En ESO, como sincronizamos los secrets con secrets nativos de k8s, si tienes problemas de conectividad puedes seguir accediendo al secret presente en tu clúster; cuando se restablezca la conexión, simplemente continuará la resincronización.
Con SSCSID, si pierdes conectividad, los montajes del csi driver dejan de funcionar si hay reinicios y demás. Están trabajando en eso, no estoy seguro de cuál es el avance: doc. Tendrías que consultarlo con ellos.
ESO será solo un deployment de operator en tu clúster.
SSCSID tendrá un daemonset de proveedor con privilegios que se encargará de hacer los montajes en tus pods.
¿Hay otras opciones?
Si buscas una alternativa segura para traer secrets desde servicios de gestión de secrets directamente a un volumen y sin usar el Kubernetes Secrets Store CSI Driver, vale la pena que le eches un vistazo a esto.
Además, en 2001 Abdellfetah SGHIOUAR, Dev Advocate de Google, escribió un artículo interesante que cubre otras opciones para almacenar secrets en GKE. Puedes verlo aquí.
**Primeros pasos con** el add-on Secret Manager para GKE
Para empezar, hay que habilitar el add-on Secret Manager en tu clúster. También puedes crear un clúster nuevo con este flag. Asegúrate de reemplazar los valores de CLUSTER_NAME y REGION/ZONE.
gcloud beta container clusters update <CLUSTER_NAME> \
--enable-secret-manager \
--location=<ZONE/REGION>
Asegúrate también de tener Workload Identity Federation en tu clúster.
Después de habilitar el add-on Secret Manager, deberías ver dos APIs nuevas disponibles con la versión secrets-store.csi.x-k8s.io/v1
$ kubectl api-resources | grep secrets-store
secretproviderclasses secrets-store.csi.x-k8s.io/v1 true SecretProviderClass
secretproviderclasspodstatuses secrets-store.csi.x-k8s.io/v1 true SecretProviderClassPodStatus
Para comunicarnos con Secret Manager, hay que otorgar los permisos requeridos a la service account de Kubernetes que vamos a usar.
Primero, creemos el namespace de k8s y la service account que usaremos en nuestro clúster.
kubectl create ns secret-manager-access
kubectl create sa secret-manager-access-sa
Luego, usaremos Workload Identity Federation para otorgar los permisos correctos a nuestra service account de K8s. Asegúrate de reemplazar el Project ID y el Project Number en las variables.
PROJECT_NUMBER=<ADD_YOUR_PROJECT_NUMBER>
PROJECT_ID=<ADD_YOUR_PROJECT_ID>
NAMESPACE=secret-manager-access
gcloud projects add-iam-policy-binding projects/star-sorceress \
--role=roles/secretmanager.secretAccessor \
--member=principal://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${PROJECT_ID}.svc.id.goog/subject/ns/${NAMESPACE}/sa/secret-manager-access-sa \
--condition=None
PD: Workload Identity Federation cambió hace poco la forma de configurarse. Si quieres saber más, revisa este blog post donde un colega de DoiT lo explica en profundidad.
A continuación creamos nuestro super secret en Google Secret Manager, junto con su primera versión:
echo "This is my awesome secret, please don't share!" > super-secret.txt
gcloud secrets create super-secret --replication-policy="automatic" --data-file="super-secret.txt"
Ahora hay que crear el Custom Resource SecretProviderClass. Este se vinculará al secret de GCP que creamos antes. No olvides incluir tu Project ID.
kubectl apply -f - <<EOF
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: super-secret
spec:
provider: gke
parameters:
secrets: |
- resourceName: "projects/<PROJECT_ID>/secrets/super-secret/versions/1"
path: "super-secret.txt"
EOF
Configura el volumen del Pod
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
name: test-pod
namespace: secret-manager-access
spec:
serviceAccountName: secret-manager-access-sa
containers:
- name: test-pod
image: google/cloud-sdk:slim
command: ["sleep","infinity"]
volumeMounts:
- mountPath: "/var/secrets"
name: super-secret
volumes:
- name: super-secret
csi:
driver: secrets-store-gke.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: super-secret
EOF
Verifiquemos si el secret ya está disponible:
kubectl exec -it test-pod -- cat /var/secrets/super-secret.txt
This is my awesome secret, please don't share
Ventajas del Secret Manager CSI Driver:
- Seguridad reforzada: los secrets nunca se almacenan dentro de los pods, lo que reduce la superficie de ataque.
- Gestión simplificada de workloads: con workload identity ya no hace falta gestionar credenciales dentro de los pods.
- Mayor configurabilidad: el control granular sobre el acceso a los secrets permite definir permisos muy específicos.
- Logs de auditoría centralizados: todos los intentos de acceso a secrets quedan registrados en Secret Manager para auditarlos con mayor facilidad.
Conclusión
Al adoptar el add-on Secret Manager para GKE te beneficias de un Secret Manager CSI Driver totalmente gestionado, con el que mejoras significativamente la postura de seguridad de tu GKE y simplificas la gestión de secrets dentro de tus aplicaciones. Con control centralizado, montaje automatizado y un control de acceso robusto, el CSI Driver te permite enfocarte en construir y desplegar tus aplicaciones con confianza.
Referencias:
https://github.com/kubernetes-sigs/secrets-store-csi-driver
https://github.com/GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp
https://cloud.google.com/secret-manager/docs/secret-manager-managed-csi-component#migrate
https://github.com/external-secrets/external-secrets/issues/478#issuecomment-964413129
https://medium.com/google-cloud/consuming-google-secret-manager-secrets-in-gke-911523207a79
https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity
https://github.com/doitintl/kube-secrets-init
¡Espero que este post te haya resultado útil! Si tienes alguna duda, déjanos un comentario abajo.
Si todavía no conoces a DoiT International, vale la pena que nos eches un vistazo. Nuestro equipo está listo para conocerte y entender tus necesidades de cloud engineering. Conformados exclusivamente por talento senior de ingeniería, nos especializamos en consultoría avanzada de diseño arquitectónico en la nube y asesoría en debugging. ¡Ponte en contacto y conversemos!