Lion Cipher Lab

Issue dynamic, short-lived database credentials with Vault

• Identity & Access Management
• Intermediate
• ~50 min
• Free · no account required

Why it matters

Almost every application talks to a database, and the overwhelmingly common way it authenticates is a single long-lived password. That one password gets copied into every app config, every deployment manifest, every developer's .env, and — because it is easy — into git history where it lives forever. It is shared, so when it leaks you cannot tell WHICH service or person used it, you cannot revoke one consumer without breaking all of them, and in practice it never gets rotated because rotating it means coordinating a change across everything that holds a copy. That is the static-secret problem…

What you'll learn

• naming the concrete failure of the shared static database password — copied into N configs, sitting in git history, never rotated, and impossible to attribute to one consumer or revoke in isolation
• defining secret, lease, TTL, secrets engine, and role inline, so the dynamic-secret model has no undefined terms
• standing up a self-contained lab on your own machine: a postgres:16 container plus a Vault dev server, with nothing paid, nothing remote, and no real database ever touched
• enabling and configuring Vault's database secrets engine against Postgres with a Vault-only admin connection and the built-in postgresql-database-plugin
• writing a role whose creation_statements mint a least-privilege Postgres user with a GRANT and bounded default_ttl / max_ttl
• generating credentials with `vault read database/creds/<role>`, reading the returned username, password, lease_id and lease_duration, and connecting to Postgres to prove they work and are read-only
• reading the role twice and seeing two DIFFERENT users, which is what per-consumer attribution actually looks like
• measuring revocation: `vault lease revoke <lease_id>` drops the Postgres user, and the same creds that worked a moment ago now FAIL to connect — the before/after that is the deliverable
• judgment: when to reach for dynamic secrets, why they beat a static password, and the honest costs — Vault availability, TTL/renewal discipline, protecting the admin credential, and the systems where this simply does not apply

Steps in this lab

1. The problem: one shared database password, copied everywhere and never rotated
2. Recap: start Postgres in a container and a Vault dev server (own machine only)
3. Give Vault its own admin user in Postgres (don't reuse the superuser)
4. Enable the database engine and configure the Postgres connection
5. Create a role: the template that mints a short-lived, least-privilege user
6. Generate creds and USE them — and prove two reads give two users
7. Measure revocation: revoke the lease, watch the same creds STOP working
8. Judgment: when dynamic secrets win — and the honest costs of adopting them

Open the full interactive lab →