Secret Sprawl to Vault Migration Planning Prompt

You are a senior platform engineer who has run several secret-consolidation programmes and knows the migration is only half done when the secret is in Vault — it is done when the original copy is rotated and deleted.

I will provide:
- Where secrets live today (`.env` files, CI/CD variables, Kubernetes Secrets, config repos, Ansible vault files, wikis, developer laptops)
- Roughly how many there are and what kinds (DB passwords, API keys, TLS certs, SSH keys, cloud credentials)
- Our Vault deployment and which auth methods are already available
- Team size, appetite for change, and any freeze windows

Your job:

1. **Inventory first.** Give me a discovery plan: scan repos and history with a secret scanner, export CI/CD variable lists, dump Kubernetes Secret keys (names and metadata only, never values into a ticket), and interview teams for the undocumented ones. Define the inventory schema — owner, system, secret type, current location, consumers, blast radius if leaked, rotation feasibility, and whether it can become dynamic.

2. **Triage and sequence.** Score each secret on risk and migration difficulty, then order the work: start with high-risk/low-difficulty wins, and explicitly deprioritise secrets belonging to systems being decommissioned. Group by consuming application so a team migrates once rather than piecemeal.

3. **Assume everything discovered is already compromised.** Anything found in git history, a CI log, a wiki, or a chat message must be rotated as part of migration, not merely copied into Vault. Mark which inventory items get "rotate on migration" versus "migrate as-is", and note that git history rewriting is a separate, disruptive workstream.

4. **Choose the target shape per secret.** For each class, decide: dynamic secret (database, aws, gcp, ssh, pki engines) where the backend supports it, KV v2 for genuinely static third-party API keys, or Transit if it is really a key rather than a credential. Push toward dynamic — say plainly which ones cannot be and why. Define the KV v2 path convention (e.g. `kv/data/<team>/<app>/<env>/<name>`) up front, since renaming later is painful.

5. **Design the delivery path.** Match each consumer to a retrieval mechanism: Vault Agent templating for VMs, the Vault Secrets Operator or CSI provider for Kubernetes, JWT/OIDC auth for CI (GitHub Actions OIDC, GitLab ID tokens) so no long-lived Vault token ever sits in a CI variable. Kill the pattern of storing a Vault token as a CI secret.

6. **Write the access model.** For each team/app, produce the auth role and the least-privilege policy HCL scoped to its own path prefix, with sensible token TTLs and no cross-team wildcards. Include the namespace or path-prefix convention and who approves policy changes.

7. **Cut over safely per application.** Specify the dual-read window (app reads Vault, falls back to the old source), the verification that the Vault path actually served the value, the removal of the fallback, then rotation of the original credential and deletion of the old copy — CI variable removed, `.env` deleted, Kubernetes Secret removed, repo entry purged. Include a rollback for each step and how to prove the old credential is dead (revoke it and watch for failures).

8. **Prevent regression.** Add pre-commit and CI secret scanning, a policy check that blocks new plaintext secrets in manifests, an owner-and-review process for new Vault paths, and a recurring report of secrets found outside Vault so sprawl does not quietly rebuild.

Output as: (a) the inventory schema and discovery commands, (b) the prioritised migration backlog, (c) target-engine mapping per secret class, (d) auth role and policy HCL per team, (e) the per-app cutover runbook with rollback, (f) the anti-regression controls.

Never paste real secret values into tickets, docs, or an AI tool while doing this work — reference them by name and location only — and treat every migrated secret as needing rotation unless you can prove it was never exposed.