Dynamic Secrets and Leasing

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.

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 USER on the database, returning a fresh username and password.
• When the lease expires, the vault runs DROP USER automatically.

The app never sees a long-lived password it gets a temporary one tied to its identity and lease.

When an application needs database access, it asks the vault for a credential. The response is a unique, freshly created username and password plus a lease describing how long it is valid.

Every consumer gets its own credential. If two pods of the same service start, they receive two different usernames making per-consumer auditing possible at the database level.

A lease is a contract that says this secret is valid for this long. Every dynamic secret carries a TTL (time to live) and an optional max TTL.

• default_ttl how long the credential lives before expiring.
• max_ttl the absolute ceiling, even with renewals.

When the lease expires, the vault revokes the credential it actively deletes the database user. Expiry is not just a flag; it triggers real cleanup. This is what makes leaked dynamic secrets self-healing: a stolen credential is useless within the TTL window.

Long-running apps that outlive a lease must renew it before expiry. Renewal extends the TTL up to the max TTL, after which the app must request a fresh credential.

Operators can also revoke a lease immediately the kill switch during an incident. Revoking a lease deletes the underlying credential right away, regardless of remaining TTL.

You can even revoke all leases under a prefix to instantly cut off an entire service or environment.

Dynamic secrets are not limited to databases. Vault and similar tools generate short-lived credentials for many systems:

• Cloud IAM temporary AWS/GCP/Azure access keys via STS-style assume-role.
• SSH signed, short-lived SSH certificates instead of static keys.
• PKI/TLS certificates issued on demand with short validity.
• RabbitMQ, MongoDB, Consul ephemeral service credentials.

The pattern is identical everywhere: request, use briefly, auto-expire. Static long-lived cloud keys are a frequent breach source; dynamic IAM credentials eliminate them.

Consider a leaked credential under each model:

• Static the password is valid until a human notices, rotates it, and updates every consumer. The exposure window is days or months.
• Dynamic the credential expires within its TTL (often minutes to an hour) and was scoped to one consumer with minimal permissions. The exposure window is tiny and the damage is contained.

Dynamic secrets convert rotation from a painful manual project into an automatic, continuous property of the system.

Dynamic secrets are powerful but require the vault to hold a highly privileged root credential for each backend it can create the users it issues. This concentrates risk in the vault.

Mitigations:

• Rotate the root credential itself so even the vault does not retain the original admin password.
• Scope the root account to exactly the permissions needed to create and drop users nothing more.
• Isolate and monitor the vault host aggressively, since it is now a high-value target.

Vault can rotate its own root credential so that after setup, no human knows it.

Apps must be written to expect credentials to change. With static secrets, code reads a password once at startup. With dynamic secrets, code must:

• Fetch a credential and note its lease TTL.
• Renew the lease, or re-fetch a new credential before expiry.
• Reconnect gracefully when an old credential is revoked.

A common pattern is a sidecar agent that handles the lease lifecycle and rewrites a local secret file, so the app simply reloads its config. Connection pools must also be refreshed so they do not cling to an expired credential.

Not every secret can be dynamic. Some third-party APIs issue one long-lived key that cannot be generated on demand. For these static secrets, apply compensating controls:

• Store them in the vault, never in code.
• Scope them to least privilege.
• Rotate them on a schedule (covered next lesson).
• Monitor their usage for anomalies.

The rule of thumb: prefer dynamic; when forced to use static, rotate and audit relentlessly.

CI/CD pipelines are a prime use case. A pipeline traditionally holds long-lived deploy keys a juicy target. With dynamic secrets, the pipeline:

• Authenticates to the vault using its OIDC identity (e.g. GitHub Actions OIDC token).
• Requests short-lived cloud credentials valid only for the duration of the job.
• Lets them expire automatically when the job ends.

No long-lived deploy key ever exists. A compromised pipeline log leaks a credential that is already dead by the time anyone reads it.

Test your understanding of leases and dynamic secrets.

You learned how short-lived, auto-expiring credentials transform secrets management.

• Dynamic secrets are generated on demand, unique per consumer, and auto-expire unlike reused static secrets.
• A lease defines a TTL and max TTL; on expiry the vault revokes the credential with real cleanup.
• Leases can be renewed by long-running apps or revoked instantly as an incident kill switch.
• Dynamic secrets work for databases, cloud IAM, SSH, PKI, and more shrinking the blast radius and automating rotation.
• The trade-off is a privileged root credential in the vault rotate and tightly scope it.
• Apps and CI/CD must be written to handle expiry; prefer dynamic, and rotate static secrets when they are unavoidable.

Next, we cover rotating keys and detecting leaks when they slip through.