Credenciales dinámicas de corta vida

Cuando una aplicación pide una credencial dinámica, el gestor devuelve el usuario temporal y una concesión (lease) con un identificador y un tiempo de vida. Mientras la concesión está viva, la credencial funciona. Al vencer, el gestor la revoca y borra el usuario de la base de datos. Si la aplicación necesita más tiempo, renueva la concesión, pero sin pasar nunca del max_ttl del rol.

La concesión también sirve para revocar a mano: se puede revocar una concesión, o todas las de un rol por prefijo, sin esperar a que venzan.

Cada rol del motor tiene un default_ttl (cuánto dura una concesión si no se pide otra cosa) y un max_ttl (el techo al que se puede renovar). Una credencial «temporal» con un techo de semanas se parece mucho a una estática.

Las reglas internas de Zurriago, en reglas.txt, ponen un tope. Cruza esa regla con los cuatro roles de roles-base-datos.txt.

Una concesión está viva mientras su hora de vencimiento no haya llegado. Las que ya vencieron ya no permiten entrar a ninguna base de datos. Para saber la superficie expuesta en un momento dado hay que contar solo las vigentes.

El archivo concesiones.txt dice que su corte es el 14 de octubre de 2026 a las 10:00. Cuenta las concesiones que a esa hora siguen vigentes.

Una credencial dinámica atribuye cada uso a quien la pidió: eso es una ventaja de auditoría que las contraseñas compartidas no tienen. Pero solo sirve si se mira. La regla 2 de Zurriago separa lo que piden las cuentas de servicio de lo que piden las personas.

Revisa quién solicitó cada concesión y compáralo con la regla.

Suponte que un servicio con el rol de escritura está comprometido. Esperar a que sus credenciales venzan deja una ventana abierta; reiniciar la aplicación no cierra las concesiones ya emitidas, que siguen siendo usuarios válidos de la base de datos.