HashiCorp Vault Dynamic Secrets Design 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.