Dynamic Database Credentials with Vault: Enable, Configure, and Verify Short‑Lived Access

Problem and Immediate Takeaway

Applications that need database credentials often hard‑code usernames and passwords, which creates rotation and security headaches. Vault can automatically generate short‑lived credentials for a database, letting the application request a fresh username/password only when the current lease expires. The result is reduced exposure and no code changes.

Mechanism Overview

Vault’s database secrets engine acts as a bridge between Vault and a database. After the engine is enabled, a role is defined that tells Vault:

• Which database user Vault uses to connect (the “auth” user).
• The TTL range for the temporary credentials.
• The maximum number of rotations per lease.

When an application calls /v1/database/creds/, Vault authenticates with the auth user, creates a temporary database account, writes the credentials to a lease, and returns them. The lease duration is enforced by Vault; after it expires the credentials are revoked automatically.

Worked Configuration Example

# 1. Enable the database secrets engine (requires root or a policy that allows secret enable)
vault secrets enable -path=database database

# 2. Configure the connection to the database (replace placeholders)
vault write database/config/mydb \\
    plugin_name=postgresql-database \\
    connection_url="postgresql://{{username}}:{{password}}@db.example.com:5432/myapp" \\
    username="vault_admin" \\
    password="vault_secret"

# 3. Define a role that specifies TTL and rotation
vault write database/roles/app-reader \\
    db_name=mydb \\
    creation_statements="CREATE USER \"{{name}}\" WITH PASSWORD \"{{password}}\"; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \\
    default_ttl="1h" \\
    max_ttl="4h" \\
    rotation_interval="15m"

# 4. Retrieve short‑lived credentials (requires a token with read permission on the role)
export ROLE=app-reader
curl -s \\
  -H "X-Vault-Token: $VAULT_TOKEN" \\
  http://127.0.0.1:8200/v1/database/creds/$ROLE \\
  | jq .

The curl command returns JSON similar to:

{
  "data": {
    "username": "temp_user_7f3a2b",
    "password": "g9K$3Lz!qP",
    "lease_duration": 3600,
    "lease_renewable": false,
    "lease_lease_id": "database/creds/app-reader/7f3a2b"
  }
}

After the lease_duration (here 1 hour) the credentials become invalid. The application can renew the lease before expiration if lease_renewable is true, but the typical pattern is to request a new set of credentials when the old ones are about to expire.

Verification Steps

1. Check the lease TTL stored in the secret’s metadata: vault read -format=json database/creds/app-reader. The lease_duration field should match the value set in the role (1h).
2. Attempt a database connection using the returned username and password. The connection should succeed while the lease is active and fail with “password authentication failed” after the lease expires.
3. Inspect Vault audit logs for /v1/database/creds/app-reader entries. Each successful request must show a “generate” operation and a corresponding “revoke” when the lease ends.

Limits and Common Mistakes

• Lease TTL too long: Setting default_ttl or max_ttl to several hours or days reduces the frequency of rotation, undermining the security benefit of dynamic credentials.
• Missing read policy for the role: If the role’s policy does not grant read access on the database, applications will receive “permission denied” errors when trying to use the credentials.
• Static auth user for Vault: Using the same permanent database user that applications use for authentication prevents Vault from creating new temporary accounts, causing rotation to stall and potentially locking out the auth user.
• Overly restrictive allowed database users: The role’s allowed_uses or db_name settings may exclude the usernames the application expects, leading to connection failures.

Rollback Considerations

All configuration changes modify Vault state. To revert a misconfiguration, you can:

• Disable the database secrets engine: vault secrets disable database (removes all generated credentials).
• Delete the role: vault delete database/roles/app-reader.
• Remove the database configuration if you no longer need it: vault delete database/config/mydb.

These commands require the same permissions used to create the resources; they will immediately affect any active leases, so coordinate with applications before executing.

Practical Check for Success

After completing the steps, run the verification commands listed above. If the lease TTL matches the role definition, a test connection succeeds before expiry and fails afterward, and audit logs show generate/revoke events, the feature is operating as intended.