Overview
Secrets management replaces ad hoc credential handling, hardcoded values in source, secrets pasted into environment variables or config files, with a centralized system that stores, provisions, rotates, and audits access to every credential a system needs. The real security gain isn't just "one place to look," it's the shift to short-lived, dynamically-issued secrets: a credential minted on demand and automatically expiring bounds the damage of a leak to its lease window instead of leaving a static password valid indefinitely. Every step down from that ideal, environment variables, shared service-account credentials, manually rotated keys, reintroduces a class of risk a centralized, automated secrets manager was built specifically to remove.
Quick Reference
| Pattern | Risk level | Why |
|---|---|---|
| Hardcoded in source | Highest | Committed to version control history permanently, visible to anyone with repo access |
| Environment variable | Medium | Readable by the whole process, easily logged or dumped in crash reports |
| Long-lived secret in a secrets manager | Lower | Centralized, audited, rotatable, but still valid until manually revoked |
| Dynamic, short-lived secret | Lowest | Automatically expires; a leak is only useful for its remaining lease |
Syntax
# Retrieve a secret at runtime instead of reading it from an env var
# or config file; the call itself is authenticated and audited.
aws secretsmanager get-secret-value --secret-id prod/orders-db/passwordExamples
# A pre-commit hook that blocks a commit containing what looks like
# a credential, catching the mistake before it ever reaches history.
git diff --cached | grep -E "AKIA[0-9A-Z]{16}" && \
{ echo "Blocked: possible AWS access key in commit"; exit 1; }Deleting a leaked secret from a file doesn't undo the leak
The value still exists in commit history, in any clone or fork already made, and possibly in CI logs. Treat a committed secret as compromised the moment it's pushed: revoke and rotate it at the source first, clean up history second.
Visual Diagram
Common Mistakes
- Treating deletion of a leaked secret's file as the fix, instead of revoking and rotating the credential at its source first.
- Storing secrets only in environment variables and calling it done, missing that they're process-readable and commonly end up in logs or crash dumps.
- Sharing one service-account credential across multiple applications, making it impossible to tell which one leaked it when it eventually does.
- Rotating secrets manually on an ad hoc schedule instead of automating rotation, which reliably drifts to "whenever someone remembers."
Performance
- Fetching a secret from a centralized secrets manager adds a network round trip on first retrieval; caching the value in memory for the life of the process (with a refresh before expiry for dynamic secrets) keeps steady-state overhead negligible.
- Short-lived secrets require the application to handle renewal before expiry; an application that doesn't will fail requests when its credential lapses, so lease duration has to be chosen with the workload's actual restart/refresh cadence in mind.
Best Practices
- Never hardcode a secret in source or commit one to version control; use pre-commit scanning to catch it before it happens, not just after.
- Prefer dynamic, short-lived secrets over long-lived static ones wherever the backing system supports issuing them.
- Use a dedicated secrets manager, not environment variables alone, for anything more sensitive than local development convenience.
- Automate rotation on a schedule rather than relying on a person to remember; treat any credential that can't be rotated automatically as a gap to close.