Cloud Security In progress
Intermediate 16 min read Cloud Security
Secrets Management in the Cloud
Stop treating secrets as config and start treating them as identity: vaulting, rotation, short-lived credentials, and the pre-commit scan that catches them early.
secretsvaultrotationshort-lived credentialssecret scanninggitleaks
Introduction
What is this?
Secrets management is the discipline of storing credentials in a purpose-built service with access control, rotation, and audit — instead of in config, artifacts, and commit history.
Motivation
Why do you need it?
- A leaked secret is the single most reusable attack primitive in the cloud: one key opens a sliding door.
- Rotation turns a leak from 'game over' into 'contained while we rotate'.
- Scanning for secrets pre-commit catches the leak before the word 'push' is even typed.
Think about it
Mental model
Imagine
A ring of keys in one drawer
Think of
A lock-smith who issues keys on demand and logs the copies
The drawer leaks once and everything is open; the locksmith revokes one key and life goes on.
Mechanics
How it works
- A vault (e.g. cloud secret store / Vault / SOPS+age) keeps the value out of code: applications fetch at runtime.
- Access control + audit bind every fetch to an identity; short-lived credentials render the secret near-useless if leaked.
- Rotation can be automated: new key in vault, app fetches next, old key revoked after a grace period.
- Commit scanning (gitleaks/trufflehog) blocks patterns and history-rescans to purge the past.
Fetch-on-demand, not bake-in-as-config
Appneeds a credential at runtime
Vaultauthz check + audit entry
Secretfetch short-lived value
Useprocess completes
Rotateon schedule or after a leak
Real world
In production
- A deployment pipeline fetches DB credentials from the vault seconds before use and never persists them to disk.
- A secret-scanner blocks a committed AWS key and auto-forces rotation of the linked IAM user.
- A platform rotates a TLS cert from the vault automatically, ending the 'expired cert at 2am' ticket tier.
Guidelines
Best practices
- Move secrets out of config/env history into a vault with RBAC and audit.
- Prefer short-lived/federated credentials wherever the platform allows.
- Scan commits and PRs for secrets; treat a hit as an incident, not a lint error.
- Rotate on a schedule AND immediately after any suspected leak — grace windows are exploitable.
Watch out
Common mistakes
- Committing .env with a real key 'once' to fix a build; the police of history never forgets.
- Exporting a secret to a CI log 'temporarily' and never rotating after the near-miss.
- Using the vault but granting admin to everyone because setup was tedious.
- Rotating the value but leaving the old one in a pinned artifact, still valid on the edge.
When things break
Debugging tips
- When a rotated pipeline fails, check which vault path/version it fetched — stale refs, not the secret, are usually the culprit.
- For a leaked-key investigation, list access history first: what could it touch in the exposure window.
- Validate a rotation by attempting the old value after the grace window — it must fail.
Security
Security considerations
- A secret surfaced in logs is an incident: rotate, revoke, scan the history, and inspect the blast radius.
- Always prefer revoke-and-rotate over 'sanitize and continue' — the leaked copy still works.
Interviews
Interview checkpoint
Practice
Hands-on lab
Secret-Hunt Your Own History and Purge It
40 min · intermediate
Objectives
- Scan a repo you own for secrets with gitleaks.
- Simulate a leak and confirm the finding.
- Plan the rotate/revoke response and rewrite history safely.
Secret-Hunt Your Own History and Purge It
40 min · intermediate
0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself
Quick quiz
0/2
1
The best response to finding a secret in a pushed commit is...
2
A short-lived credential is safer because...
Go deeper