Dynamic Database Credentials in HashiCorp Vault

Why Static Database Credentials Become a Liability

Many organizations embed database usernames and passwords into application configuration files, shell scripts, or CI/CD pipelines. These static credentials rarely expire, proliferate across environments, and become attractive targets for attackers who gain long-term access without needing to rotate secrets. Manual rotation is often skipped, and auditing who used which credential when is notoriously difficult.

Vault’s Dynamic Database Credentials Model

HashiCorp Vault addresses this by generating short-lived database credentials on demand. When an application or human requests a credential, Vault contacts the database, creates a temporary user with scoped privileges, returns the credentials, and automatically revokes the user when the time-to-live (TTL) expires. This eliminates static credentials from source code and reduces the window of opportunity for credential misuse.

The feature relies on Vault’s database secrets engine, which must be enabled and pointed at the target database via a connection configuration. A role then defines what database users can be created, what privileges they receive, and how long they live. Because the role acts as a policy boundary, you can restrict a developer’s role to SELECT on specific tables, for example, without touching the database’s global admin accounts.

Hands-On: Generating a Short-Lived PostgreSQL Token

To try this, you’ll need a Vault CLI client authenticated with a token that has sudo-level capabilities, and a running PostgreSQL instance reachable from the Vault server. The following steps use PostgreSQL as the example database, but the same pattern applies to MySQL, Oracle, and MSSQL via their respective plugins.

1. Enable the database secrets engine

   vault secrets enable database

   Run on a terminal where the Vault CLI is available and VAULT_ADDR/VAULT_TOKEN are set. This command requires a token with the sudo capability or an elevated policy. If the engine is already enabled, the command returns an informational message rather than an error.

2. Configure the connection to PostgreSQL

   vault write database/config/my-postgres plugin_name='postgresql' connection_string='<connection-string>'

   Replace <connection-string> with your actual PostgreSQL connection string (e.g., postgresql://vault_user:vault_pass@db-host:5432/mydb). The plugin name postgresql is built-in for Vault 1.12+; older versions may require the postgres plugin. Required permission: sudo on database/config/. Expected check: the command returns Success! Enabled database secret engine. Risk: an incorrect connection string will cause the configuration to fail, and Vault will not be able to reach the database.

3. Define a role with scoped privileges

   vault write database/roles/my-postgres-role db_name='my-postgres'

   Placeholders: my-postgres-role is the role name; my-postgres refers to the config created in step 2. Required permission: sudo on database/roles/. Expected check: success output confirms the role is written. Risk: overly broad role statements can grant unintended privileges.

4. Generate credentials and verify

   vault read database/creds/my-postgres-role

   The output includes a username and password. Use the password immediately to connect to the database. After the TTL (default 15 minutes), the user is automatically revoked. Attempting to reconnect after expiry should fail.

   Practical verification: After the TTL window, attempt a connection; denial confirms the dynamic lifecycle works as expected.

Trade-offs, Limitations, and Practical Verification

While dynamic credentials significantly reduce credential sprawl, the setup introduces considerations: Plugin compatibility is version-specific; network policies must allow Vault to reach the database; privilege scoping must be careful to prevent escalation; TTL tuning balances security and load. To verify the full lifecycle, automate a script that generates a credential, waits past the expiry, and confirms the database user no longer exists.

Actionable Closing

If you’re currently managing static database credentials, start by enabling Vault’s database secrets engine in a non-production environment, configure a minimal role for read-only access, and generate a token to observe the automatic revocation. From there, iterate on TTL values, role statements, and network configurations to match your organization’s security posture. The investment in proper role design pays off in reduced audit friction and a smaller attack surface.