Killing Long-Lived Secrets: Dynamic Credentials With Vault

The static database password sitting in your application’s config file is the single credential most likely to be leaked, and the one that does the most damage when it is. It does not expire, it is copied everywhere, and nobody can tell you who has seen it.

Every regulated firm I have reviewed has some version of the same problem. A long-lived password to a production database lives in an environment variable, a Kubernetes secret, a CI variable, a developer’s .env file, and three places nobody has documented. It was set in 2021. It has never been rotated because rotating it means coordinating a change across every service that holds a copy, and that is a project nobody wants to own. When a laptop is compromised or a repository is pushed public, that credential is valid, privileged and standing. The incident-response question is not whether it works but how much it can reach.

The durable fix is not a better vault for the password. It is to stop having a durable password at all. Instead of storing a secret, you mint one on demand, scoped to the workload that asked for it and set to expire in minutes. HashiCorp Vault’s dynamic secrets do exactly this, and the shift in thinking matters more than the tooling.

Static versus dynamic, and why it changes the threat model

A static secret is written once and read many times. Its whole value to an attacker is that it keeps working. Rotation is the only defence, and rotation is precisely the operation that static secrets make painful, because the credential is coupled to every consumer that cached it.

A dynamic secret inverts the model. The credential does not exist until a workload authenticates and requests it. Vault holds a privileged connection to the database and, on request, issues the SQL to create a brand-new user with a scoped grant and a short lifetime. The workload receives a username and password that belong only to it, that no other service shares, and that Vault will delete when the lease ends. There is nothing durable to steal, because the thing an attacker would want to exfiltrate is already gone by the time they could use it. This is the argument I set out in more depth in ending the long-lived database password, and it is the cleanest reduction in blast radius available to most estates.

The moving parts

Three concepts do the work, and it is worth naming them precisely because the vendor documentation blurs them.

• The secrets engine is the plugin that knows how to talk to a backing system. The database engine speaks to PostgreSQL, MySQL, SQL Server and others; there are equivalent engines for AWS, GCP and Azure that mint short-lived cloud credentials the same way.
• The lease is the contract attached to every dynamic credential. It carries a time-to-live and a maximum time-to-live. When the TTL expires, or when you revoke it, Vault runs the deletion statement and the database user ceases to exist.
• The auth method is how a workload proves who it is before it is allowed to ask for anything. In practice this is the workload’s own identity, not a bootstrap password: a Kubernetes service account token, an AWS IAM role, or AppRole for machines that have neither.

The auth method is where firms under-invest. If you authenticate to Vault with a static token pasted into config, you have moved the standing secret one hop and called it progress. The point is to anchor Vault access in an identity the platform already issues and can attest to, so the credential the workload actually holds is itself short-lived and non-transferable. That is the same discipline I argue for around scoping and rotating API keys: the identity has to be the thing that is hard to steal.

What it looks like in practice

Here is the database engine configured against PostgreSQL, issuing a read-only credential with a one-hour default lifetime and a hard ceiling of twenty-four hours. The role’s creation statement is the exact SQL Vault runs to mint each user; keep the grant as narrow as the workload genuinely needs.

# Enable the database secrets engine
vault secrets enable database

# Point Vault at the database using a connection user that can manage roles.
# allowed_roles restricts which Vault roles may use this connection.
vault write database/config/reporting-db \
    plugin_name="postgresql-database-plugin" \
    allowed_roles="report-reader" \
    connection_url="postgresql://{{username}}:{{password}}@db.internal:5432/reporting" \
    username="vault_mgr" \
    password="$VAULT_DB_BOOTSTRAP_PW"

# Immediately rotate the bootstrap password so only Vault holds it.
vault write -force database/rotate-root/reporting-db

# Define the dynamic role: the SQL below is run per request to mint a user.
vault write database/roles/report-reader \
    db_name="reporting-db" \
    default_ttl="1h" \
    max_ttl="24h" \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";"

# A workload (already authenticated to Vault via its own identity) asks for
# credentials. It receives a unique user, a password, and a lease_id.
vault read database/creds/report-reader

# When the work is done, the lease is revoked and the database user is dropped.
# It would also expire on its own at the TTL without this call.
vault lease revoke database/creds/report-reader/<lease_id>

The workload never sees a password you set. It authenticates as itself, reads database/creds/report-reader, and gets a credential that is useless to anyone else and expired within the hour. If that credential leaks into a log or a crash dump, the exposure window is measured in minutes, not years.

What a supervisor and an incident actually test

The governance payoff is that dynamic secrets make two hard questions answerable. Who had access to production data, and when? With standing passwords the honest answer is a shrug. With dynamic secrets every credential is a lease with an identity, a timestamp and a scope, and Vault’s audit log records the request. You can produce, on demand, the list of workloads that were issued database access in a given window, which is exactly the evidence an ICT-risk review or a breach post-mortem needs and rarely gets. This is why I treat the tool as a governance decision, not a plumbing one: the auditability is the point, not a side effect.

Two operational cautions before anyone treats this as free. Dynamic secrets add a hard runtime dependency: if Vault is unreachable, workloads cannot renew leases, so its own availability and seal/unseal handling become resilience-critical and need the same rigour as the database itself. And the backing system has to tolerate the churn of short-lived users, which usually means confirming connection-pooling behaviour and grant cleanup before you turn TTLs down low. Neither is a reason to keep the static password. They are the reasons to plan the rollout rather than bolt it on.

One footnote on tooling choice, since it now affects procurement. HashiCorp relicensed Vault under the Business Source Licence in 2023, and the Linux Foundation’s OpenBao is a maintained open-source fork of the last MPL-licensed codebase. The dynamic-secrets model described here is identical in both; the decision between them is about licensing and support posture, not architecture.

The test of your secrets posture is simple. Take the credential your most critical service uses to reach its database, and ask how long it has been valid. If the answer is measured in years, you do not have a secret. You have a liability with a password field.