Secrets in Config to HashiCorp Vault Blueprint
This blueprint removes plaintext secrets from config and Git and centralizes them in HashiCorp Vault. It introduces per-workload auth, least-privilege policies, dynamic short-lived credentials, automatic rotation, and treats every legacy secret as compromised.
What and Why
Secrets in config means credentials, API keys, and database passwords sitting in plaintext config files, environment variables, or committed to Git. These leak through logs, error reports, backups, and repository history, and they are almost never rotated, so a single leak can persist for years. HashiCorp Vault centralizes secrets with access control, audit logging, leasing, and dynamic secrets that are generated on demand and expire automatically.
The migration moves from static, long-lived, scattered secrets to centrally managed, short-lived, audited ones. The biggest wins come from dynamic secrets: instead of one shared database password baked into every app, each instance receives a unique credential that Vault revokes when its lease ends, so a leaked credential is useless within minutes.
Phases
Discovery. Scan code, config, CI variables, container images, and Git history for secrets using detection tools (gitleaks, trufflehog). Build an inventory: what the secret is, who uses it, where it lives, and how it is currently rotated (usually never). Classify by sensitivity and blast radius, and treat every discovered secret as already compromised.
Design. Stand up Vault with high availability (Raft integrated storage) and auto-unseal backed by a cloud key management service. Choose authentication methods per workload: Kubernetes auth for pods, AppRole for CI, and cloud IAM auth for cloud workloads, so identities authenticate without a bootstrap secret problem. Define secret engines: key-value v2 for static secrets, and dynamic engines (database, cloud, PKI) for generated credentials. Map policies to the principle of least privilege so each identity reads only what it needs, and manage Vault configuration with Terraform.
Pilot. Migrate one application end to end. Replace its config-file secrets with Vault reads via the Vault Agent sidecar, the Secrets Store CSI driver, or direct API calls. Validate that the app starts, renews leases automatically, and handles secret rotation without a restart where possible. Confirm audit logging captures every access.
Migration. Roll out application by application. Convert static secrets to KV v2, and convert database and cloud credentials to dynamic secrets so each instance gets unique, short-lived credentials. Wire CI to fetch deploy-time secrets via AppRole rather than stored pipeline variables, removing secrets from the CI system itself.
Rotation. Enable automatic rotation and leasing. Set time-to-live (TTL) values so credentials expire and are reissued, and configure Vault to rotate root credentials for managed engines. Rotate every secret that ever existed in plaintext, then purge secrets from Git history and invalidate the old values.
Key Risks and Mitigations
- Secret exposure during migration. Treat every discovered secret as compromised and rotate it. Scrub repository history (filter-repo/BFG) and invalidate old credentials so a copied repo cannot reuse them.
- Outage on lease expiry. Apps that ignore lease renewal break when secrets expire. Use Vault Agent for automatic renewal, set sensible TTLs, and test expiry and renewal behavior in staging.
- Skills gap. Vault policies, auth methods, and the unseal model are unfamiliar. Start with one secret engine, document policy patterns, automate Vault config with Terraform, and run game-day exercises for seal/unseal and recovery.
Recommended Tooling
HashiCorp Vault with HA storage and auto-unseal, Vault Agent or the Secrets Store CSI driver for injection, dynamic secret engines (database, cloud, PKI), Terraform for Vault configuration-as-code, and secret-scanning tools (gitleaks/trufflehog) in CI.
Success Metrics
Track secret rotation frequency, count of plaintext secrets remaining in code/config, audit coverage of secret access, and MTTR for credential compromise.
Prerequisites
A secret-scanning capability, an HA platform for Vault with a KMS for auto-unseal, an identity source for auth methods, and a policy for treating discovered secrets as compromised and rotating them.