Vault Database Secrets Engine: Designing and Operating Dynamic Credentials

Every time an application requests credentials, Vault hands back a unique DB user and password that automatically expire when the TTL runs out. That is the core idea behind the Database secrets engine.

This article walks through why dynamic issuance is safer, the minimum setup steps, rotation and revocation, policy design, and the points that tend to show up on the exams — all in one place.

Why Dynamic Credentials: Reducing Risk and Operational Load

With dynamic credentials, Vault creates a short-lived DB user on each request and reliably tears it down when the TTL expires or it is explicitly revoked. Compared to long-lived shared passwords or manual handoffs, this dramatically shrinks the blast radius of any leak.

Auditability is also strong — Vault's audit log records who fetched credentials under which role and when. During incidents or rollbacks, revoking at the lease level takes effect immediately.

• Principle: each request = temporary user + unique password + lease
• TTL / Max TTL control the lifetime; expiration triggers automatic teardown (e.g. user deletion)
• Audit logs plus policies give you both least privilege and accountability

Architecture and How Leases Work

The Database secrets engine connects to the DB through a plugin (e.g. postgresql-database-plugin) and runs the SQL defined in the role to create a user. Vault binds the generated credentials to a lease and runs the revocation SQL when the TTL expires.

The application only needs read access to Vault — Vault handles the DB-side creation and deletion on its behalf. This decouples DB administrative privileges from the application itself.

• Creation statements: SQL that creates the user and grants privileges
• Revocation statements: SQL that drops or disables the user on expiry
• Lease: tracks TTL and renewability; expiration triggers automatic teardown

Dynamic credential issuance flow

Minimum Setup (PostgreSQL Example)

The following is a minimal walkthrough. The DB connection user (e.g. vault_admin) needs permission to create users, grant privileges, and drop users. Adjust the connection URL and TLS settings for your environment.

In creation_statements, accept the temporary username and password as Vault template variables, and grant only the minimum privileges required.

• In production, require TLS on the DB connection and keep Vault's privileges strictly minimal
• Set default_ttl and max_ttl carefully to match your requirements
• Grant the application read access only on database/creds/<role>

Configuration and credential fetch via the Vault CLI (PostgreSQL)

export VAULT_ADDR=https://vault.example.com
export VAULT_TOKEN=hvs.xxxxx

# 1) Databaseシークレットエンジンを有効化
vault secrets enable database

# 2) DB接続設定（postgresql-database-plugin）
vault write database/config/my-postgresql \
  plugin_name=postgresql-database-plugin \
  allowed_roles=app-readonly \
  connection_url="postgresql://{{username}}:{{password}}@db.example.com:5432/postgres?sslmode=require" \
  username="vault_admin" \
  password="s3cr3t"

# 3) ロール定義（読み取り専用の一時ユーザを作成）
vault write database/roles/app-readonly \
  db_name=my-postgresql \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\"; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO \"{{name}}\";" \
  revocation_statements="REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM \"{{name}}\"; DROP ROLE IF EXISTS \"{{name}}\";" \
  default_ttl=1h \
  max_ttl=24h

# 4) アプリが資格情報を取得（動的）
vault read database/creds/app-readonly
# 出力例
# Key                Value
# lease_id           database/creds/app-readonly/xxxxx
# lease_duration     1h
# lease_renewable    true
# password           A1b2C3d4e5f6g7h8
# username           v-token-app-readonly-1693258841-abcde

# 5) 最小権限ポリシー（アプリ用）
cat <<'EOF' > app-readonly.hcl
path "database/creds/app-readonly" {
  capabilities = ["read"]
}
EOF
vault policy write app-readonly app-readonly.hcl

# 必要ならアプリ用トークンを発行（例）
vault token create -policy=app-readonly -display-name=app-A

# 6) 失効（インシデント対応など、即時剥奪）
vault lease revoke database/creds/app-readonly/xxxxx

# 7) 接続ユーザのローテーション（定期的なベストプラクティス）
vault write -f database/rotate-root/my-postgresql

Operations: Best Practices for TTL, Leases, Rotation, and Teardown

Leases can be renewed within the bounds of max_ttl. Renewal extends Vault's revocation schedule and pushes back the user-drop timing. If long-lived connections are not required by the role, keep default_ttl short.

The connection user — the fixed account Vault uses to reach the DB — can be rotated with rotate-root. This shortens the window during which the static Vault-to-DB credential is exposed.

• lease renew extends the deadline; it cannot exceed max_ttl
• During incidents, use lease revoke for immediate revocation
• Run database/rotate-root/<db_name> on a regular cadence
• Review the audit log to confirm who pulled which role

Policy Design: Minimizing App Permissions and Enforcing Boundaries

As a rule, give the application only read access on database/creds/<role>. Write and list operations are unnecessary. Separating paths per role clarifies the boundaries between services.

Even for the same application, use distinct role names for dev / staging / prod so credentials cannot cross environments. Separating namespaces or mount paths is also effective.

• Scope paths to a single role
• Prevent privilege bleed with per-environment roles and paths
• Review policies and audit logs on a regular schedule

Troubleshooting and Exam-Relevant Points

Common failures include insufficient privileges on the connection user (cannot CREATE ROLE or GRANT), bad escaping in creation_statements, and DB connections that don't meet TLS requirements. Start by reading both the Vault log and the DB server log side by side.

For the Associate / Ops exams, common topics include the relationship between Lease / TTL / Max TTL, the meaning of rotate-root, the effect of lease revoke, and constraints around allowed_roles.

• If the role name is missing from allowed_roles, the fetch fails
• Misconfiguring max_ttl < default_ttl causes a creation error
• Clock drift (no NTP) makes TTL behavior look erratic
• Watch out for DB-side object privilege inheritance and default privileges

Check Your Understanding

Frequently Asked Questions