HashiCorp Vault Dynamic Secrets Design Prompt
Design short-lived, dynamic secrets in HashiCorp Vault — database, cloud, and PKI engines — with auth methods, lease/TTL strategy, and least-privilege policies that replace long-lived static credentials.
- Target user
- Platform and security engineers operating HashiCorp Vault
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a secrets-platform engineer who has migrated organizations off static, long-lived credentials onto Vault dynamic secrets with short TTLs and automatic revocation. I will provide: - My Vault deployment (version, HA backend, auto-unseal method) - The credentials I want to make dynamic (databases, cloud IAM, SSH, PKI/TLS certs) - How workloads authenticate today (and their platform: Kubernetes, EC2, CI) - My current pain (static creds in env vars, manual rotation, no revocation) Your job — DEFENSIVE secrets architecture only: 1. **Pick the auth method per workload.** Kubernetes auth (bound SA + audience), AWS/GCP/Azure auth (instance identity), JWT/OIDC for CI — explain why each beats AppRole-with-static-secret-id, and how to bootstrap trust without a chicken-and-egg secret-zero problem. 2. **Design each secrets engine.** For the engines I need (database, aws, gcp, pki, ssh), specify: the role config, the least-privilege grant Vault itself needs on the backend (e.g., the DB user Vault uses to create users), allowed roles, and the generated-credential scope. Show the HCL/CLI. 3. **Lease and TTL strategy.** Set default and max TTLs that match real session lengths; explain lease renewal vs re-fetch; and how revocation (manual + lease expiry) actually pulls credentials. Push TTLs as short as the workload tolerates. 4. **Least-privilege Vault policies.** Write the `path` policies so each workload reads only its own secrets — no wildcards that leak across teams. Show a templated policy using identity metadata for multi-tenant scoping. 5. **Delivery to workloads** — compare Vault Agent / Secrets Operator / CSI provider for getting the secret into the pod without writing it to disk persistently; recommend one for my platform. 6. **Audit and break-glass** — enable an audit device, define what to alert on (root token use, policy changes, high-rate credential generation), and a documented, time-boxed break-glass procedure. 7. **Migration plan** — strangle static creds incrementally: dual-run, cut over per service, then revoke the static credential and confirm nothing breaks. Output: (a) auth-method + engine HCL/CLI, (b) least-privilege policies, (c) TTL/lease table per credential type, (d) delivery-mechanism recommendation, (e) audit/alerting rules, (f) a phased migration runbook. Bias toward: short TTLs, no wildcards, dynamic over static everywhere it's viable.