What is cloud secrets management?
Cloud secrets management is the practice of storing, distributing, rotating and auditing credentials — API keys, database passwords, tokens and certificates — so that no application holds a long-lived secret in code or configuration. Secrets live in a dedicated store, are fetched at runtime, and every access is logged.
The problem is distribution, not storage
Nearly every team has a secrets store. Very few have a secrets problem that the store alone solves, because the hard part was never where to keep a secret — it was how an application gets one at the moment it needs it, without a human pasting it somewhere first.
That gap is where secrets end up in places they should not be: an environment variable in a task definition, a Kubernetes Secret mounted as plaintext, a CI variable, a Terraform state file, a Slack message from 2023, a commit from a Friday afternoon.
Each of those is a copy. A secret with copies cannot be rotated, because nobody knows how many there are.
What actually goes wrong
| Failure | Why it happens | What it enables |
|---|---|---|
| Hardcoded credentials | Fastest path to a working build | Anyone with repository read access has production access |
| Long-lived static keys | Rotation breaks things, so nobody rotates | A key leaked in 2022 still works today |
| Secrets in environment variables | Every runtime supports it | Readable by any process, and printed by most crash handlers |
| Over-broad key policies | Least privilege is fiddly to get right | One compromised service decrypts everything |
| No audit trail | Access logging is off by default in places | A leak is undetectable and its blast radius unknowable |
| Secrets in state and logs | A side effect, never a decision | Copies accumulate where nobody looks |
Secrets management and key management are not the same thing
They get conflated because the same vendors sell both.
Key management (KMS) deals with cryptographic keys: generating them, controlling who may encrypt or decrypt with them, and ideally never letting the key material leave the boundary. The question is who may perform this cryptographic operation?
Secrets management deals with credential values: storing them, handing them to workloads, rotating them and recording who fetched what. The question is which identity may read this value right now?
They meet at encryption at rest — a secrets store encrypts its contents with a key from KMS — but a well-run KMS does not stop a database password appearing in a container image.
The rotation problem, honestly
Rotation is where most programmes stall, and the reason is mechanical rather than cultural: rotating a secret means every consumer must pick up the new value without an outage, and most consumers read their secret exactly once at startup.
The approaches that work in practice all remove the long-lived secret rather than rotating it faster:
- Workload identity. The workload authenticates as itself — an instance role, IRSA, Workload Identity, a federated OIDC token — and receives short-lived credentials. There is no static secret to leak.
- Dynamic secrets. The store creates a credential on request with a short lease and revokes it after.
- Dual-secret rotation. Two valid credentials at a time, so the new one is deployed before the old one is revoked.
Everything else is scheduling pain around a design that assumed secrets are permanent.
What good looks like
- No secret in source, ever — enforced by a pre-commit hook and a repository scan, not by review.
- One store per environment, with access granted to identities rather than people.
- Short-lived by default. Workload identity where the platform supports it; leases where it does not.
- Every access audited, with alerts on access from an unexpected identity or region.
- Scoped keys. One key per data domain, so one compromise does not decrypt the estate.
- Detection in the pipeline and at rest — scanning repositories, images, IaC, CI configuration and cloud resource metadata, because that is where copies actually accumulate.
The last point is the one most often missed: a secrets programme that only inspects the secrets store is auditing the one place secrets are handled correctly.
Frequently asked questions
What is the difference between secrets management and key management?
Key management (KMS) controls cryptographic keys and who may encrypt or decrypt with them. Secrets management stores and distributes credential values — passwords, API keys, tokens — to the workloads that need them. A secrets store usually uses KMS to encrypt itself, but they answer different questions.
Why are hardcoded secrets still so common?
Because they work immediately and the alternative requires the workload to have an identity before it has a credential. The fix is rarely a policy; it is making the correct path as fast as the wrong one, then scanning to catch what slips through.
How often should cloud secrets be rotated?
Frequency matters less than lifetime. A secret rotated every 90 days is still valid for 90 days if it leaks on day one. Short-lived credentials issued to a workload identity remove the question rather than answering it.
Where do leaked cloud secrets usually come from?
Copies rather than the store itself — source control, container image layers, CI variables, Terraform state, environment variables and log output. Any secrets programme that only inspects the vault is inspecting the one place things are done correctly.