Protect · Secrets management
HashiCorp Vault
Vault stores and brokers secrets, issues dynamic database and cloud credentials, manages PKI and encrypts data as a service. Kubernetes workloads authenticate with service account tokens instead of static secrets.
On this page
What it does
Provides authenticated, audited access to secrets through engines: KV, dynamic database credentials, PKI, transit encryption and cloud IAM.
Where it fits
Protect stage: the source of truth for secrets consumed by CI (via OIDC/JWT auth) and by workloads (Vault Agent, CSI driver or External Secrets Operator).
Quick start
vault login -method=oidc
vault kv put secret/payments/api db_password=... # prefer dynamic secrets over static KV
vault read database/creds/payments-readonly # short-lived DB credential
vault write auth/kubernetes/role/payments-api bound_service_account_names=api bound_service_account_namespaces=payments policies=payments ttl=1hCommon pitfalls
- Treating Vault as a KV store only; dynamic secrets are the actual win.
- Root token left enabled after initialisation.
- No audit device configured — you cannot answer “who read this secret?”.
On this site
- Secrets and Configuration Security: Vault in dev mode with a scoped policy, a token with a TTL and a use limit, and the audit device showing who read which path with values HMAC-ed.
Articles about HashiCorp Vault
Secrets and Configuration Security: Images, Kubernetes, Vault and Rotation
The secrets lifecycle for a cloud workload: credentials recovered from image history and deleted layers, a build that leaves nothing behind, Secrets in etcd before and after encryption at rest, rotation, and Vault TTLs.