Secrets Management
The problem
Applications need credentials (API keys, database passwords, encryption keys) to function, but those same credentials are exactly what an attacker wants — storing them in plain environment variables or, worse, source code, leaves them exposed to anyone with repository or server access.
Why now
Environment and configuration already established environment variables as the standard way to inject configuration into a process; secrets management is the deliberate hardening of that exact same mechanism for the specific, sensitive subset of configuration that must also be protected from unauthorized viewing, using TLS's encrypted-channel principle applied to storage instead of transit.
Mental model
A secrets manager is a locked box with an access-controlled key: instead of a plaintext value sitting in a config file or environment variable anyone with server access can read, a secret lives encrypted in a dedicated store, fetched only at runtime by processes explicitly authorized to read it — narrowing exposure from 'anyone who can read this file' to 'only this specific service, only when it actually needs the value.'
Requires
- Environment & ConfigurationLinux
Secrets management is a stricter, access-controlled version of the same configuration-injection mechanism already covered; you need plain environment variables as the baseline before appreciating what a dedicated secrets manager adds on top.
- TLS & Encryption BasicsNetworking
A secrets manager protects credentials using the same encryption principles already covered, applied to data at rest and in transit to and from the secrets store, not just to an HTTP connection.
Used in
- HashiCorp Vault, AWS Secrets Manager, and similar dedicated secrets stores
- CI/CD pipelines injecting deployment credentials without exposing them in logs or source
- Credential rotation, changing a secret's value without redeploying every service that uses it
- Preventing secrets from being accidentally committed to source control
Projects
- Migrate a hardcoded API key from a config file into a secrets manager (or a local equivalent), fetched at runtime instead of stored in the codebase
- Set up a pre-commit check that scans for accidentally committed secrets (API keys, passwords) before they reach source control
Examples
- A database password fetched from a secrets manager at application startup never appears in the codebase, a config file, or a container image layer
- Rotating a compromised API key in a secrets manager updates it for every service reading it at runtime, without needing to redeploy any of them
Resources
Mastery checklist
- I can explain why hardcoding secrets in source code or config files is a security risk
- I can migrate a hardcoded secret to a secrets manager or equivalent runtime-fetched pattern
- I can explain credential rotation and why it's easier with centralized secrets management
- I can set up a basic safeguard against committing secrets to source control