La auditoría SOC 2 es uno de los exámenes más rigurosos para cualquier empresa que maneja datos sensibles. Un equipo de ingeniería compartió recientemente cómo su infraestructura de gestión de secretos en Kubernetes no solo superó la auditoría, sino que transformó por completo su flujo de trabajo. La clave estuvo en combinar External Secrets Operator (ESO) con el CSI Driver, una dupla que permitió pasar de la simple encriptación en reposo a un proceso documentado y auditable de rotación de credenciales.
El reto inicial era claro: los secretos almacenados en Git, incluso cifrados, y un gestor de secretos externo no se reconcilian automáticamente. Esto generaba riesgos de credenciales obsoletas y dificultades para demostrar controles durante la auditoría. La solución implementada eliminó por completo la referencia a objetos Secret nativos de Kubernetes por parte de los pods, lo que redujo la superficie de ataque y simplificó la trazabilidad.
La arquitectura que marcó la diferencia
El corazón de esta arquitectura es el CSI Driver, que monta un volumen tmpfs en /var/run/secrets/ y sincroniza los valores cada vez que se escribe un archivo. Cuando un secreto rota, el driver reescribe el archivo y envía una señal SIGHUP al proceso del pod mediante el parámetro refreshInterval. Esto garantiza que las aplicaciones siempre trabajen con credenciales vigentes sin necesidad de reinicios manuales.
Para la autenticación, el equipo optó por JWT a través de IRSA (IAM Roles for Service Accounts) en lugar de credenciales estáticas. La cuenta de servicio se vincula a un rol de IAM con permisos limitados exclusivamente a secretsmanager:GetSecretValue. Este enfoque de privilegios mínimos es fundamental para cumplir con los controles de acceso de SOC 2.
Configuración de intervalos de actualización
El equipo estableció un refreshInterval de 60 segundos como valor predeterminado seguro para auditorías. Sin embargo, para secretos especialmente sensibles, redujeron el intervalo a 15 segundos. Esta flexibilidad permite equilibrar seguridad y rendimiento según la criticidad de cada credencial.
Un detalle crucial: el CSI Driver monta el secreto de AWS en el sistema de archivos del pod de forma sincrónica al inicio. Si un secreto rota entre el arranque del pod y la primera sincronización, el pod podría tener credenciales obsoletas. Para mitigar esto, se añadió un hook lifecycle.preStop que ejecuta /var/run/secrets/refresh antes de enviar SIGTERM. Así se asegura que el pod siempre tenga la versión más reciente antes de terminar.
Rotación sin reinicios: el reto de las aplicaciones
Por defecto, el CSI Driver utiliza su función de rotación que escribe nuevos secretos sin reiniciar el pod. Pero esto solo funciona si la aplicación lee el archivo de secretos periódicamente, no solo al inicio. El equipo identificó que 12 de sus aplicaciones cacheaban credenciales al arrancar, por lo que activaron fileEventRefresh: true para forzar la recarga. Las otras 8 aplicaciones leían el secreto en cada petición, por lo que no requerían reinicio alguno.
Esta distinción es vital para mantener la disponibilidad durante la rotación. La conclusión es clara: no todas las aplicaciones reaccionan igual, y es responsabilidad del equipo de plataforma entender el comportamiento de cada una.
Auditoría y trazabilidad: el verdadero desafío
AWS Secrets Manager registra las llamadas a GetSecretValue en CloudTrail, pero la identidad registrada es la cuenta de servicio de ESO, no el pod que consumió el secreto. La auditoría exigía responder preguntas como: “¿qué pod consumió este secreto a las 14:32?”. La solución fue habilitar los eventos de datos de CloudTrail en Secrets Manager, no solo los eventos de gestión. Esto tiene un costo de 0.10 dólares por cada 100,000 eventos, pero el equipo lo consideró una inversión justificada para cumplir con los requisitos de auditoría.
Con esta configuración, cada acceso a un secreto queda registrado con el contexto necesario para reconstruir la cadena de custodia. Es un ejemplo de cómo la observabilidad debe extenderse más allá de las métricas y los logs de aplicación, alcanzando también la capa de gestión de identidades y secretos.
Integración con agentes de compilación Windows
El equipo también enfrentó el reto de autenticar agentes de compilación Windows que necesitaban acceder a servicios de AWS desde contenedores. Para ello, utilizaron la herramienta de montaje WebDAV ScsDriver para Windows, que permite montar los mismos buckets de S3 que ESO sincroniza en Kubernetes. Esto resulta útil cuando un runner de CI en Windows necesita descargar un paquete de secretos fresco durante la compilación. El flujo de rotación de credenciales funciona porque el agente Windows vuelve a montar el recurso compartido en cada trabajo de CI.
Esta integración demuestra que la gestión de secretos no se limita a un solo sistema operativo o plataforma. La consistencia en la rotación y el acceso es clave para mantener una postura de seguridad sólida en entornos híbridos.
Lecciones aprendidas y mejores prácticas
La experiencia de este equipo deja varias enseñanzas valiosas para quienes enfrentan auditorías similares:
- No confíes solo en la encriptación en reposo. La auditoría SOC 2 exige demostrar controles de acceso y rotación, no solo cifrado.
- Automatiza la rotación y hazla auditable. Herramientas como ESO y CSI Driver permiten documentar cada paso del ciclo de vida de un secreto.
- Habilita eventos de datos en CloudTrail. Aunque tenga costo, es la única forma de saber qué pod consumió un secreto y cuándo.
- Adapta la configuración a cada aplicación. No todas las apps manejan la rotación de la misma manera; algunas requieren reinicios o recargas forzadas.
- Considera entornos híbridos. Los agentes Windows también pueden beneficiarse de una gestión centralizada de secretos.
La pregunta final que plantea el equipo es directa: ¿cómo es tu stack de rotación de secretos? ¿Vault + ESO, AWS Secrets Manager + ESO, u otra combinación? La respuesta dependerá de las necesidades específicas de cada organización, pero lo que está claro es que la gestión manual de secretos ya no es una opción viable en entornos regulados.
En un mundo donde las brechas de seguridad son cada vez más costosas, invertir en una arquitectura robusta de gestión de secretos no es solo una buena práctica, sino un requisito para competir en industrias reguladas. La experiencia de este equipo demuestra que es posible superar una auditoría SOC 2 sin sacrificar la agilidad operativa.
