Tus secretos de Kubernetes acaban en texto plano en el disco

El error de montar secretos de Kubernetes como volúmenes: por qué tus contenedores los ven en disco y cómo evitarlo con CSI Secret Store

¿Sabías que ese secreto que crees tener a buen recaudo en tu clúster probablemente está escrito en texto plano sobre el disco de cada nodo? Sí, tal cual. Y no, no es un bug. Es cómo funciona el mecanismo de volúmenes de secretos que llevamos usando desde siempre.

Vamos a hablar de algo que a muchos nos explotó en la cara cuando empezamos a tomarnos en serio la seguridad en Kubernetes. Porque una cosa es que tu app funcione y otra muy distinta es que los secretos que maneja no estén tirados por ahí como si fueran apuntes de primero de carrera.

El mecanismo que todos usamos (y casi nadie cuestiona)

Cuando creas un Secret en Kubernetes y lo montas como volumen en un Pod, ¿qué pasa por debajo? Pues algo bastante simple: el kubelet del nodo recibe ese secreto, lo escribe en el disco del propio nodo —normalmente en algo tipo /var/lib/kubelet/pods/<id>/volumes/...— y luego lo proyecta dentro del contenedor como archivos.

Traducción: ese secreto que tú creías encapsulado en etcd con cifrado en reposo acaba materializado como un fichero en el filesystem del nodo. Cualquiera con acceso al nodo, con un cat bien colocado, lo lee.

Y aquí viene lo bonito: si tienes diez réplicas de tu app repartidas en diez nodos, tienes diez copias de ese secreto en diez discos distintos. Multiplica eso por la cantidad de secretos que manejas y ya tienes un mapa de tesoros repartido por todo tu clúster.

¿Y esto es un problema real o solo paranoia?

Depende de tu modelo de amenazas, pero seamos honestos: en la mayoría de entornos productivos serios, sí lo es. Piensa en escenarios concretos.

Un atacante que consigue acceso a un nodo —por un contenedor comprometido, por una vulnerabilidad en el runtime, por un maldito SSH mal configurado— no solo tiene el nodo. Tiene todos los secretos que ese nodo esté sirviendo en ese momento. Tokens de API, credenciales de bases de datos, claves de firma, certificados... lo que sea.

Y no hace falta ser un APT con presupuesto de agencia estatal. Un script de post-explotación básico que haga un find por /var/lib/kubelet te saca oro puro en cuestión de segundos.

Añádele que muchos backups de nodos, snapshots de discos y herramientas de observabilidad capturan ese filesystem sin filtros. Ahí van tus secretos de paseo.

La solución que llevas años ignorando: CSI Secret Store

Vale, respira. Que no cunda el pánico. Existe una forma bastante elegante de evitar que tus secretos toquen disco: montarlos directamente desde el gestor de secretos externo usando el driver CSI correspondiente.

La idea es esta. En lugar de tener los secretos almacenados en etcd y proyectados como ficheros, tu Pod monta un volumen CSI que habla directamente con tu proveedor de secretos —puede ser un vault corporativo, un gestor cloud, lo que uses— y sirve los valores en memoria al contenedor. Sin pasar por disco. Sin dejar rastro en el nodo.

Piénsalo como la diferencia entre guardar la llave de casa debajo del felpudo y llevarla encima. Ambos abren la puerta, pero solo uno de los dos métodos hace que el ladrón se vaya con las manos vacías si entra a mirar.

Cómo funciona esto en la práctica

El flujo es más sencillo de lo que parece:

1. Instalas el driver CSI de tu proveedor de secretos en el clúster.
2. Creas un SecretProviderClass que define qué secretos quieres traer y cómo mapearlos a ficheros dentro del contenedor.
3. En tu Pod, montas un volumen CSI que referencia esa clase.

Cuando el Pod arranca, el driver se autentica contra el gestor externo, recupera los secretos y los sirve al contenedor a través del volumen montado. El kubelet nunca escribe nada en disco. El nodo nunca ve el valor del secreto.

¿Y el rendimiento? Prácticamente idéntico al montaje tradicional. La latencia de red contra el gestor de secretos se paga una vez al montar, y luego los valores quedan cacheados en memoria del propio driver. No vas a notar la diferencia en tu app.

¿Y la rotación? Aquí viene la parte buena. Muchos drivers soportan refresco automático: si el secreto cambia en el gestor externo, el volumen montado se actualiza sin reiniciar el Pod. Adiós al clásico "reinicia el deployment para que coja la nueva credencial".

Los peros que nadie te cuenta

No todo es color de rosa, y sería un mal artículo si te lo pintara como la panacea. Hay que asumir ciertos costes.

• Dependes de un componente externo. Si tu gestor de secretos se cae, tus Pods nuevos no arrancan. Necesitas pensar en alta disponibilidad también ahí.
• La curva de aprendizaje existe. Configurar autenticación entre el clúster y el gestor de secretos no es trivial, y cada proveedor tiene sus rarezas.
• La depuración se complica. Cuando algo falla, ya no es un simple kubectl describe pod. Ahora tienes que mirar logs del driver CSI, del proveedor, de la identidad del workload... Vamos, que un rato de sufrimiento te espera la primera vez.

Pero honestamente, todo eso se paga solo la primera vez que evitas un incidente de seguridad. Porque un secreto filtrado no se arregla con un rollback.

Cuándo merece la pena dar el salto

Mi criterio, y aquí hablo como alguien que ha visto ambos lados:

• Si estás en producción con datos sensibles de verdad —credenciales de clientes, claves de firma, tokens con permisos serios—, deberías estar usando CSI Secret Store ayer.
• Si estás en un entorno de desarrollo, en un side project o en un clúster de pruebas donde los secretos son de juguete, sigue con los volúmenes clásicos. No te compliques.

La línea divisoria es simple: ¿qué pasa si ese secreto se filtra? Si la respuesta es "nada grave", no te molestes. Si la respuesta es "se lía parda", invierte el tiempo.

El detalle que se nos olvida siempre

Hay algo que me revienta cuando hablamos de seguridad en Kubernetes. Nos obsesionamos con RBAC, con network policies, con admit controllers... y luego dejamos los secretos tirados en disco como si fueran configmaps.

La seguridad no es una capa. Es una propiedad que atraviesa todo el sistema. Y si tu capa más sensible —las credenciales— está sentada en el filesystem de cada nodo, tienes un agujero por muy bonito que sea el resto del castillo.

CSI Secret Store no es la solución a todos tus problemas. Pero cierra una puerta que llevaba demasiado tiempo abierta. Y a veces, cerrar una puerta es exactamente lo que necesitas para dormir tranquilo.

Así que te dejo la pregunta en el aire: ¿sabes ahora mismo cuántas copias de tus secretos hay repartidas por los discos de tu clúster? Si la respuesta te hace dudar, ya sabes por dónde empezar el lunes.