Administración segura de secretos en Kubernetes

Una contraseña de base de datos en un Helm-Chart, un token de API en la CI-Pipeline y una clave de nube como variable de entorno: así es como comienzan muchos problemas de seguridad en Kubernetes. Gestionar secretos en Kubernetes no significa simplemente escribir valores en un objeto de Kubernetes. Es una tarea operativa que conecta los derechos de acceso, los procesos de implementación, la rotación, la auditabilidad y la respuesta a incidentes.

Para las empresas medianas, esta no es una cuestión de seguridad académica. Si las credenciales de acceso llegan a un repositorio de Git o si demasiados workloads tienen acceso a claves productivas, surgen riesgos concretos: accesos no autorizados a datos, bloqueos de releases, costosas respuestas a incidentes y, en el peor de los casos, un incidente de seguridad que debe ser reportado. Una solución viable debe permitir que los equipos entreguen más rápido, sin delegar la seguridad en pasos manuales individuales.

Lo que los secretos de Kubernetes pueden hacer - y lo que no

Un secreto de Kubernetes almacena valores de configuración sensibles como contraseñas, certificados, tokens o claves privadas. Los pods pueden montar estos valores como archivos o recibirlos como variables de entorno. Esto es práctico, pero aún no constituye una gestión segura de secretos.

El punto clave: Base64 no es cifrado. Un secreto estándar está simplemente codificado. Quien tenga acceso a la API de Kubernetes, una copia de seguridad o un archivo de manifiesto con este contenido, puede leer el valor sin un esfuerzo significativo. Además, el cifrado en el almacenamiento etcd debe configurarse explícitamente. Sin Encryption at Rest, los secretos pueden estar en texto claro.

Por lo tanto, los secretos de Kubernetes son un mecanismo de entrega útil para las aplicaciones, pero rara vez son la única bóveda adecuada para credenciales de acceso de alta criticidad a largo plazo. La arquitectura que es adecuada depende de las necesidades de protección, el entorno de la nube, los sistemas de identidad existentes y la cantidad de equipos. Para un clúster pequeño y bien delimitado, los secretos de Kubernetes bien cifrados pueden ser suficientes. En el caso de múltiples entornos, rotaciones frecuentes o requisitos regulatorios, un gestor de secretos dedicado suele ser la opción más robusta.

Gestionar secretos en Kubernetes: la base de seguridad

La base consiste en unas pocas medidas que deben trabajar juntas. Configuraciones individuales no resolverán el problema.

Primero, los secretos deben almacenarse cifrados en el clúster. Esto incluye una configuración de Encryption-at-Rest para el plano de control de Kubernetes, así como una clave bien gestionada para el cifrado. En las ofertas de Kubernetes gestionadas, algunas partes de esto suelen estar preconfiguradas. Sin embargo, debe verificarse qué clave se utiliza, quién puede administrarla y si también se han re-cifrado los secretos existentes tras habilitar la función.

Igualmente central es el RBAC. El acceso a los secretos no debe otorgarse de manera general a grupos de desarrolladores, sistemas de CI o cuentas de servicio. Un namespace por sí solo no es un límite de seguridad si los roles están definidos demasiado amplios. Un deployment típicamente necesita acceder únicamente a los secretos de su cuenta de servicio, no a todos los secretos de un namespace y mucho menos a nivel de clúster.

Los derechos de acceso como `list` y `watch` merecen atención especial. A primera vista parecen menos dañinos que `get`, pero pueden revelar metadatos y, en ciertas configuraciones, más información de la necesaria para la operación. Los derechos deben estar limitados a recursos, namespaces y workloads concretos. Revisiones regulares evitan que excepciones históricas se conviertan en riesgos permanentes.

Los registros y las herramientas de diagnóstico también deben formar parte del modelo de seguridad. Las salidas de depuración, los pasos fallidos de la pipeline o los bundles de soporte no deben contener valores de secretos. Esto afecta no solo a Kubernetes en sí, sino también a aplicaciones, sidecars y agentes de observabilidad. Un token en un sistema de registro central es prácticamente tan problemático como un token en el repositorio.

Sin secretos en texto claro en Git

GitOps crea implementaciones reproducibles, pero un repositorio de Git no es una caja de secretos. Una contraseña que se ha registrado una vez suele permanecer en commits, forks, clones locales y copias de seguridad, incluso si se elimina el archivo posteriormente. Esto también se aplica a los repositorios internos.

Para implementaciones declarativas, existen dos enfoques establecidos. El primer enfoque cifra los manifiestos de secreto antes del commit. Herramientas como SOPS o Sealed Secrets permiten guardar valores cifrados bajo control de versiones, que se descifran solo en el clúster de destino. Esto es útil para equipos que utilizan Git como fuente central para cambios en la infraestructura y gestionan cantidades manejables de secretos.

El segundo enfoque hace referencia a secretos externos desde la implementación. Un controlador lee los valores en tiempo de ejecución desde un gestor de secretos dedicado y crea o actualiza los secretos de Kubernetes necesarios. De este modo, los valores reales permanecen fuera de Git y, a menudo, también fuera de la administración diaria de Kubernetes.

Ambos modelos tienen su lugar. Los manifiestos cifrados son transparentes y fáciles de entender, pero requieren un proceso confiable para la gestión y rotación de claves. Los gestores de secretos externos reducen la difusión de valores sensibles y apoyan credenciales dinámicas, pero añaden una dependencia adicional a la plataforma. Lo decisivo es que el camino elegido permanezca automatizado, documentado y manejable en caso de un incidente.

Identidades en lugar de credenciales de acceso duraderas

El mayor apalancamiento a menudo no radica en un mejor almacenamiento de una contraseña, sino en evitar las contraseñas. Las aplicaciones que acceden a recursos en la nube deben autenticarse idealmente mediante Identidades de Workload. Así, una cuenta de servicio de Kubernetes recibe una identidad de nube claramente definida. La aplicación puede, por ejemplo, acceder a Object Storage, mensajería o un servicio de bases de datos, sin tener que manejar una clave de nube duradera en el contenedor.

Esto reduce significativamente la cantidad de secretos críticos. Además, se pueden asignar permisos con mayor precisión a los workloads y revocarse de forma centralizada. Para plataformas productivas, esto suele ser más seguro y operativamente más sencillo que una API-Key compartida que permanece sin cambios durante años en varias implementaciones.

En el caso de las bases de datos, la evaluación es más compleja. No todos los servicios admiten credenciales de acceso efímeras o basadas en identidades. Donde se permiten credenciales de bases de datos dinámicas, deben preferirse. De lo contrario, se necesita una rotación rastreable, donde la aplicación y la base de datos puedan cambiar de manera controlada a nuevos valores. Cambiar una contraseña cada 90 días manualmente suena a cumplimiento, pero provoca interrupciones si la transición no está automatizada.

La rotación debe ser un proceso operativo planificado

Rotar un secreto es más que cambiar un valor en el gestor de secretos. Las aplicaciones solo leen variables de entorno al inicio. Si un secreto se proporciona de esta manera, el pod generalmente necesita reiniciarse para que el nuevo valor tenga efecto. Los secretos montados como archivos pueden actualizarse, pero incluso en ese caso, la aplicación debe detectar los cambios y reconstruir su conexión de manera adecuada.

Por lo tanto, para sistemas críticos para el negocio, la rotación debe probarse como un deployment. Esto incluye un responsable definido, un flujo automatizado, monitoreo de errores de autenticación y un plan de recuperación. En el caso de las bases de datos, puede ser necesaria una fase de transición con dos credenciales válidas: se despliega la nueva contraseña, la aplicación cambia, y después se desactiva la contraseña antigua.

Los certificados merecen una consideración especial. Sus plazos y renovaciones deben ser monitoreados, ya que un certificado caducado a menudo solo se nota cuando una conexión falla. La emisión y renovación automatizadas reducen significativamente este riesgo, pero no reemplazan el monitoreo del estado real.

CI/CD-Pipelines como parte de la superficie de ataque

La pipeline a menudo recibe derechos más amplios que un solo desarrollador. Construye imágenes, despliega en clústeres y accede a artefactos o recursos en la nube. Un token de pipeline comprometido puede, por lo tanto, poner en peligro una gran parte de la plataforma.

La pipeline debe utilizar identidades efímeras, no trabajar con credenciales de administrador de clúster almacenadas permanentemente y solo poder desplegar en los entornos previstos. Los lanzamientos productivos pueden necesitar controles adicionales, pero los procesos manuales de copia y pega no son una arquitectura de seguridad. Es mejor tener lanzamientos rastreables en el flujo de trabajo de implementación y permisos separados para build, testing y producción.

Las imágenes de contenedor tampoco deben contener secretos. Esto puede parecer obvio, pero sucede regularmente a través de argumentos de construcción, archivos de configuración y construcciones multinivel. Un escaneo de imágenes ayuda, pero no reemplaza una regla clara: los valores sensibles se inyectan en tiempo de ejecución y nunca se almacenan en imágenes, artefactos o datos de prueba.

Comprobar, practicar, ajustar

Una estrategia de secretos efectiva es medible. Los equipos deben revisar regularmente qué secretos existen, quién puede leerlos, cuándo se rotaron por última vez y si se pueden eliminar valores no utilizados. Los registros de auditoría de la API de Kubernetes y del gestor de secretos hacen que los accesos sean rastreables. Estos datos son particularmente valiosos cuando un empleado se va, un token se expone accidentalmente o se investiga un incidente de seguridad.

Un escenario de incidente realista también forma parte de esto: ¿cómo se identifica, revoca, reemplaza y verifica un secreto comprometido en los sistemas afectados? Quien pruebe estos procesos una vez en condiciones controladas evitará decisiones apresuradas en caso de emergencia. devRocks conecta esos mecanismos de seguridad con CI/CD, observabilidad y la operación continua de la plataforma, para que las medidas de protección no frenen los lanzamientos.

Una buena gestión de secretos no se mide por el hecho de que nadie vea más contraseñas. Se refleja en que las aplicaciones acceden de manera controlada a exactamente los recursos que necesitan, y en que un valor comprometido puede ser reemplazado sin largas interrupciones en la operación.