Dynamic Secrets and Leasing
Short-lived, auto-expiring credentials.
Static vs Dynamic Secrets
A static secret is created once and reused indefinitely the same database password that ten services share for years. Static secrets are the default and the problem: they are long-lived, widely shared, and hard to rotate.
A dynamic secret is generated on demand, unique to one consumer, and automatically expires. Instead of storing a password, the vault creates a brand-new credential each time one is requested.
This single shift solves the hardest parts of secrets management: rotation becomes automatic, and the blast radius of any leak shrinks to near zero.
How Dynamic Secrets Work
Dynamic secrets require the vault to have privileged access to the backend system. The flow for a database looks like this:
- An admin configures the vault with a root DB credential and a creation template.
- An app authenticates and requests a credential.
- The vault runs
CREATE USERon the database, returning a fresh username and password. - When the lease expires, the vault runs
DROP USERautomatically.
The app never sees a long-lived password it gets a temporary one tied to its identity and lease.
# Configure Vault's database engine with a creation statement
vault write database/roles/billing-readonly \
db_name=appdb \
creation_statements="CREATE ROLE \"{{name}}\" LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON billing TO \"{{name}}\";" \
default_ttl="1h" max_ttl="24h"All lessons in this course
- The Secrets Sprawl Problem
- Vaults and Secret Stores
- Dynamic Secrets and Leasing
- Key Rotation and Detection