Cloud
Secrets Management
Storing credentials, API keys and certificates in a dedicated encrypted vault (AWS Secrets Manager, HashiCorp Vault) with access control, audit logs and automatic rotation — never in code or committed env files. It shrinks the blast radius of a leak. The bootstrap problem remains: something still needs one identity to unlock the vault.
Purpose
Secrets management centralises credentials — database passwords, API keys, signing certificates — in an encrypted vault (AWS Secrets Manager, HashiCorp Vault) with access control, audit logging and rotation. It exists because secrets scattered through code, config files and chat messages are how breaches begin.
When to Use It
Applications fetching database credentials at startup or runtime; CI pipelines injecting deploy keys; automatic rotation of credentials on a schedule or after an incident; and an audit trail of who read what, when — which spreadsheets of shared passwords cannot offer.
Trade-offs
The vault becomes critical infrastructure — if it is down, services cannot start — and the bootstrap problem never fully disappears: something must hold the first identity that unlocks the vault (solved in cloud by attaching IAM roles to compute rather than storing any key at all).
Implementation
Give workloads an identity (IAM role, Kubernetes service account) and grant each the minimum secrets it needs; fetch at runtime rather than baking into images or env files in git. Enable rotation for database credentials, alert on unusual access, and scan repos (gitleaks) to catch what still slips through.