Vault Dynamic Secrets

Vault Dynamic Secrets

Static credentials — a database password or an AWS access key that lives in a config file or environment variable — have a fundamental flaw: they do not expire. If a credential leaks through a log line, a git commit, a compromised CI runner, or a noisy shoulder-surf, it remains valid indefinitely unless someone manually rotates it. At scale, with hundreds of services, "manually rotate" means "never rotates." Dynamic secrets fix this at the architectural level: Vault generates a brand-new, time-limited credential on demand and automatically destroys it when the lease expires. There is nothing to leak that has lasting value.

The Static vs. Dynamic Credential Risk Model

Consider a typical microservices deployment. Ten services share one Postgres password stored in a Kubernetes Secret. The blast radius of a single credential compromise is all ten services and every table in the database. The attacker has days or weeks before anyone notices and rotates. With dynamic secrets, each service gets its own credential tied to its own lease. If service A is compromised, only service A's credential exists — and it expires in one hour. The attacker's window collapses from weeks to minutes.

Enabling the Database Secrets Engine

Vault ships with a database secrets engine that supports PostgreSQL, MySQL, MSSQL, MongoDB, Cassandra, Elasticsearch, and more. The pattern is identical across all of them: configure a connection, define roles with SQL templates, and let services request credentials on demand. Here is the complete setup for PostgreSQL, which is the most common production use case:

AWS Dynamic Credentials (IAM)

The AWS secrets engine follows the same pattern but calls the AWS STS or IAM API instead of a database. It can generate assumed-role credentials (temporary STS tokens via sts:AssumeRole), federated user tokens, or full IAM users with programmatic access keys. In production, assumed-role credentials are strongly preferred because they are native to AWS IAM, have built-in expiry enforced by STS, and do not require Vault to call iam:DeleteAccessKey for cleanup.

Lease Lifecycle: Renewal and Revocation

Every dynamic secret comes with a lease: a lease ID, a TTL, and a renewable flag. Vault tracks all active leases. An application should renew its lease before it expires to avoid being disconnected mid-session. If an application is being decommissioned, it should revoke the lease immediately rather than waiting for natural expiry — this is the principle of fail closed.

The Vault Agent sidecar handles the lease lifecycle automatically in most production deployments. It authenticates to Vault on behalf of the application, writes the credential to a shared tmpfs volume or to the process environment, renews leases proactively at 2/3 of the TTL, and re-fetches credentials when leases cannot be renewed. Applications consume credentials from a well-known path and never talk to Vault directly.

Policy Scoping for Dynamic Secret Roles

Each service should have a Vault policy that grants access to only the specific roles it needs. Write the policy in HCL and associate it with the service's authentication method (Kubernetes ServiceAccount, AWS IAM role, AppRole, etc.):

Why Dynamic Beats Static: Production Evidence

At companies like Lyft, Netflix, and Shopify, the migration from static to dynamic secrets produced measurable outcomes: mean-time-to-detect credential exposure dropped from days to minutes (because leaked creds expire before forensics complete), secret rotation went from a quarterly manual process to continuous and automatic, and audit trails became per-request rather than per-service. The TTL is the forcing function — when every credential expires in an hour, your entire secret management posture is permanently in rotation without any operational overhead.