Using Vault Dynamic Database Secrets to Retire Static Credentials

Most teams start with a shared database login. It lives in a config file, gets copied into a few services, and eventually nobody remembers who still has it. Rotation becomes a scheduled outage, and offboarding leaves a live credential behind. The useful takeaway is that HashiCorp Vault's database secrets engine can issue short-lived usernames and passwords on demand, but adopting it changes how your applications start and fail.

The static credential problem

A long-lived database password is a standing invitation. It grants access until someone remembers to change it, and every copy in a repository, CI variable, or laptop expands the blast radius. Manual rotation helps, but it is error-prone: a missed update in one service causes an outage, so teams often postpone rotation until the next incident forces it.

Dynamic secrets invert the model. Instead of distributing a password, the application asks Vault for a credential that expires. The database user exists only for the lifetime of a lease, which shrinks the window of exposure from months to minutes or hours.

Roles, leases, and the issuance workflow

Vault's database secrets engine is mounted at a path such as database/. Before it can issue credentials, an administrator configures a connection to the target database. That connection uses a privileged database account—often one that can create and drop users—which becomes a high-value security boundary.

A role in this engine is a template for credential lifecycle. It defines the SQL statements Vault runs to create and revoke the database user, plus a default and maximum time-to-live (TTL). The creation statement typically uses templated variables such as {{name}} and {{password}} so each request produces a unique login. The revocation statement cleans up the user when the lease ends.

Applications do not log into Vault with the database connection's privileged account. They authenticate using an auth method—AppRole, Kubernetes, JWT, or another supported method—and then request credentials for a specific role. Vault returns a temporary username, password, and lease metadata. A lease is Vault's unit of lifecycle: it carries a duration, an ID, and rules for renewal or early revocation.

A worked example: issuing and revoking a short-lived credential

The following commands assume you have the Vault CLI installed and authenticated with a token that has administrative rights. Run them from a trusted admin host or bastion, not from an application container.

1. Confirm the mount and connection

List enabled secrets engines and check that the database engine is mounted and a connection is configured:

vault secrets list

Look for a mount of type database. Then read the connection configuration to confirm the target database is reachable:

vault read database/config/my-postgres

If the connection is missing or unhealthy, credential requests will fail. This read requires a token with permission on that path.

2. Create a narrowly scoped role

Create a role that generates a login valid for one hour by default, capped at 24 hours. The SQL below is illustrative for a PostgreSQL target; exact syntax and available templated fields vary by database plugin and Vault version.

vault write database/roles/analytics-reader \
  db_name=my-postgres \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  revocation_statements="DROP ROLE IF EXISTS \"{{name}}\";" \
  default_ttl=1h \
  max_ttl=24h

The creation_statements run with the privileges of the user configured in the database connection. If that user is a superuser, the dynamic role inherits that power unless the SQL explicitly restricts it. Keep the grant list minimal.

3. Request credentials

An application or operator with a token that can read the role path can request credentials:

vault read database/creds/analytics-reader

The response includes a generated username, a password, a lease_duration, and a lease_id. Note the username format—Vault typically prefixes it with the role name and a random suffix—so you can correlate it with database audit logs.

4. Renew or revoke early

If a job needs more time, renew the lease within the role's maximum TTL:

vault lease renew <lease_id>

When the work finishes, revoke immediately rather than waiting for expiry:

vault lease revoke <lease_id>

Revocation triggers the role's revocation statements against the database. If those statements fail—for example, because the role owns a table—the database user may linger. Check your database audit logs or user catalog to confirm cleanup.

Trade-offs and failure modes

Dynamic credentials are not a free upgrade. They add latency: the first database connection in an application now includes a round trip to Vault. More importantly, they introduce a hard dependency on Vault availability. If Vault is unreachable at startup, the application cannot obtain a credential and may fail to boot.

Renewal is another sharp edge. A long-running process that outlives its lease must renew it, or the database session will break when the user is dropped. Applications need retry and renewal logic that accounts for Vault outages.

Finally, behavior is version-sensitive. Database plugin names, supported templated fields, and lease options can change across Vault releases. Confirm capabilities in your deployed version before writing role statements.

Where to start

Pick a non-production database and a read-only role with a short TTL. Configure the connection, create the role, and request credentials from the CLI. Then verify the full lifecycle: check that the database user appears after issuance and disappears after expiry or revocation. Review your database audit logs to confirm the creation and revocation statements executed as intended.

Once that loop is clean, move to a low-risk production service and instrument it for Vault latency and failure. Retiring a static password is satisfying; keeping the replacement reliable under load is the real engineering work.