Stop sharing one static database password. Have Vault generate a unique, time-limited credential per client on demand, then revoke it automatically when the lease ends.
Why: a static database password is shared, long-lived, and a nightmare to rotate — everyone has it, and revoking it breaks everyone. Vault can instead GENERATE a fresh database user per request, valid for a short lease, then delete it automatically when the lease expires. Each client gets its own credential, every one is short-lived, and a leak self-heals.
static secret: one password, shared, lives forever, painful to rotate
dynamic secret: Vault creates a unique DB user per request
▼
valid for the lease (e.g. 1h), then Vault DELETES itWhy: the database secrets engine connects to your DB with an admin account and is told how to create users. You enable it, point it at the database, and define a "role" — the SQL Vault runs to mint a user and the lease length. Note: this needs a reachable database; the commands show the shape you would run against, say, a local Postgres.
vault secrets enable databaseTell Vault how to connect (admin creds used only to create users)
vault write database/config/my-postgres \
plugin_name=postgresql-database-plugin \
connection_url="postgresql://{{username}}:{{password}}@localhost:5432/?sslmode=disable" \
allowed_roles="app" username="vaultadmin" password="adminpass"Why: a role is the template for the credentials Vault hands out — the SQL that creates the user and grants its privileges, plus how long the credential lives. creation_statements runs when a credential is requested; default_ttl sets the lease. This role makes read-only users that last one hour.
vault write database/roles/app \
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}}\";" \
default_ttl=1h max_ttl=24hWhy: now any authorized client reads the role path and Vault creates a brand-new database user right then, returning the username, password, and a lease_id. Two reads give two different users. The app uses the credential, and when the lease ends Vault drops the user from the database.
Each read mints a fresh, unique DB user
vault read database/creds/appReturns something like: lease_id database/creds/app/AbC123... password A1a-randomly-generated username v-token-app-x9y8z7
Why: every dynamic secret comes with a lease that Vault tracks. You can renew a lease to keep the credential alive, or revoke it to delete the underlying user immediately — the instant kill switch for a compromised credential. When you revoke, the DB user is gone; the app simply requests a new one.
Extend the lease
vault lease renew database/creds/app/<lease_id>Revoke now — Vault deletes the DB user immediately
vault lease revoke database/creds/app/<lease_id>