Secretos dinámicos y leasing

Un secreto estático se crea una vez y se reutiliza indefinidamente: es el caso de la misma contraseña de base de datos que diez servicios comparten durante años. Los secretos estáticos son la opción predeterminada y el problema: duran mucho tiempo, se comparten ampliamente y son difíciles de rotar.

Un secreto dinámico se genera bajo demanda, es único para un consumidor y caduca automáticamente. En lugar de almacenar una contraseña, la bóveda crea una credencial completamente nueva cada vez que se solicita.

Este sencillo cambio resuelve los aspectos más difíciles de la gestión de secretos: la rotación se vuelve automática y el radio de impacto de cualquier filtración se reduce prácticamente a cero.

Los secretos dinámicos requieren que la bóveda tenga acceso privilegiado al sistema backend. El flujo para una base de datos es el siguiente:

• Un administrador configura la bóveda con una credencial raíz de la base de datos y una plantilla de creación.
• Una aplicación se autentica y solicita una credencial.
• La bóveda ejecuta CREATE USER en la base de datos y devuelve un nombre de usuario y una contraseña nuevos.
• Cuando el lease caduca, la bóveda ejecuta automáticamente DROP USER.

La aplicación nunca ve una contraseña de larga duración: obtiene una temporal vinculada a su identidad y a su lease.

Cuando una aplicación necesita acceso a una base de datos, solicita una credencial a la bóveda. La respuesta incluye un nombre de usuario y una contraseña únicos y recién creados, además de un lease que indica durante cuánto tiempo son válidos.

Cada consumidor obtiene su propia credencial. Si se inician dos pods del mismo servicio, reciben dos nombres de usuario diferentes, lo que permite realizar auditorías por consumidor en el nivel de la base de datos.

Un lease es un contrato que establece durante cuánto tiempo es válido un secreto. Cada secreto dinámico incluye un TTL (tiempo de vida) y un TTL máximo opcional.

• default_ttl: cuánto tiempo vive la credencial antes de caducar.
• max_ttl: el límite absoluto, incluso aunque se renueve.

Cuando el lease caduca, la bóveda revoca la credencial: elimina activamente el usuario de la base de datos. La caducidad no es solo una marca; activa una limpieza real. Esto hace que los secretos dinámicos filtrados se autocorrijan: una credencial robada deja de servir dentro de la ventana del TTL.

Las aplicaciones de larga duración que sobreviven a un lease deben renovarlo antes de que caduque. La renovación amplía el TTL hasta el TTL máximo; después, la aplicación debe solicitar una credencial nueva.

Los operadores también pueden revocar un lease inmediatamente: es el interruptor de emergencia durante un incidente. Revocar un lease elimina de inmediato la credencial subyacente, independientemente del TTL restante.

Incluso puede revocar todos los leases bajo un prefijo para cortar al instante el acceso de todo un servicio o entorno.

Los secretos dinámicos no se limitan a las bases de datos. Vault y herramientas similares generan credenciales de corta duración para muchos sistemas:

• Cloud IAM: claves de acceso temporales de AWS/GCP/Azure mediante assume-role al estilo de STS.
• SSH: certificados SSH firmados y de corta duración en lugar de claves estáticas.
• PKI/TLS: certificados emitidos bajo demanda con una validez corta.
• RabbitMQ, MongoDB, Consul: credenciales de servicio efímeras.

El patrón es el mismo en todas partes: solicitar, usar brevemente y caducar automáticamente. Las claves estáticas de larga duración en la nube son una fuente frecuente de filtraciones; las credenciales IAM dinámicas las eliminan.

Considere una credencial filtrada según cada modelo:

• Estático: la contraseña sigue siendo válida hasta que una persona la detecta, la rota y actualiza a cada consumidor. La ventana de exposición dura días o meses.
• Dinámico: la credencial caduca dentro de su TTL (a menudo entre unos minutos y una hora) y está limitada a un consumidor con permisos mínimos. La ventana de exposición es diminuta y el daño queda contenido.

Los secretos dinámicos convierten la rotación, que antes era un proyecto manual y costoso, en una propiedad automática y continua del sistema.

Los secretos dinámicos son potentes, pero requieren que la bóveda almacene una credencial raíz con privilegios elevados para cada backend en el que pueda crear los usuarios que emite. Esto concentra el riesgo en la bóveda.

Medidas de mitigación:

• Rote la propia credencial raíz para que ni siquiera la bóveda conserve la contraseña de administrador original.
• Limite la cuenta raíz exactamente a los permisos necesarios para crear y eliminar usuarios, sin nada más.
• Aísle y supervise el host de la bóveda de forma rigurosa, ya que ahora es un objetivo de gran valor.

Vault puede rotar su propia credencial raíz para que, una vez completada la configuración, ningún ser humano la conozca.

Las aplicaciones deben estar escritas para prever que las credenciales cambiarán. Con secretos estáticos, el código lee una contraseña una vez al iniciarse. Con secretos dinámicos, el código debe:

• Obtener una credencial y anotar su TTL de lease.
• Renovar el lease o volver a obtener una credencial nueva antes de que caduque.
• Volver a conectarse correctamente cuando se revoque una credencial antigua.

Un patrón habitual consiste en un agente sidecar que gestiona el ciclo de vida del lease y vuelve a escribir un archivo local de secretos, de modo que la aplicación solo tenga que volver a cargar su configuración. Los pools de conexiones también deben actualizarse para que no se aferren a una credencial caducada.

No todos los secretos pueden ser dinámicos. Algunas API de terceros emiten una única clave de larga duración que no puede generarse bajo demanda. Para estos secretos estáticos, aplique controles compensatorios:

• Almacénelos en la bóveda, nunca en el código.
• Limítelos al mínimo privilegio.
• Rótelos según un calendario (se aborda en la próxima lección).
• Supervise su uso para detectar anomalías.

La regla general es: prefiera los secretos dinámicos; si se ve obligado a usar secretos estáticos, rótelos y audítelos sin descanso.

Las canalizaciones de CI/CD son un caso de uso ideal. Tradicionalmente, una canalización contiene claves de despliegue de larga duración, un objetivo muy atractivo. Con secretos dinámicos, la canalización:

• Se autentica en la bóveda mediante su identidad OIDC (p. ej., el token OIDC de GitHub Actions).
• Solicita credenciales de nube de corta duración, válidas solo durante el trabajo.
• Deja que caduquen automáticamente cuando termina el trabajo.

No existe ninguna clave de despliegue de larga duración. Un registro de canalización comprometido filtra una credencial que ya ha dejado de ser válida cuando alguien lo lee.

Compruebe su comprensión de los leases y los secretos dinámicos.

Ha aprendido cómo las credenciales de corta duración y caducidad automática transforman la gestión de secretos.

• Los secretos dinámicos se generan bajo demanda, son únicos para cada consumidor y caducan automáticamente, a diferencia de los secretos estáticos reutilizados.
• Un lease define un TTL y un TTL máximo; al caducar, la bóveda revoca la credencial y realiza una limpieza real.
• Las aplicaciones de larga duración pueden renovar los leases, o estos pueden revocarse al instante como interruptor de emergencia durante un incidente.
• Los secretos dinámicos funcionan con bases de datos, cloud IAM, SSH, PKI y mucho más; reducen el radio de impacto y automatizan la rotación.
• La contrapartida es una credencial raíz privilegiada en la bóveda: rótela y limítela estrictamente.
• Las aplicaciones y CI/CD deben estar preparadas para gestionar la caducidad; prefiera los secretos dinámicos y rote los estáticos cuando sean inevitables.

A continuación, veremos cómo rotar claves y detectar filtraciones cuando consiguen atravesar las defensas.