How Secrets Management Works
IntermediateSecrets management is how applications store and access sensitive credentials — database passwords, API keys, TLS certificates — without exposing them. Hardcoding secrets in code or config is dangerous: they leak through version control, logs, and images. A secrets manager (like HashiCorp Vault or a cloud KMS) centralises secrets, encrypts them, controls who can read each one, audits access, and can rotate them automatically — even issuing short-lived, dynamic secrets that expire on their own.
Think of a bank vault versus notes on the fridge
Writing passwords in your code is like sticking every account PIN on the fridge — anyone who walks through your kitchen (your repo, logs, or an image) sees them. A secrets manager is a bank vault: credentials are locked away encrypted, only authorised people can withdraw specific ones, every access is recorded, and the bank can reissue new keys and cancel old ones on a schedule. You ask for what you need, when you need it, and never leave it lying around.
Step by Step
Key Concepts
Centralised Secret Store
A dedicated, encrypted system (Vault, cloud secrets manager/KMS) that holds all secrets as the single source of truth, replacing secrets scattered across code, config, and environment variables.
Least-Privilege Access
Granting each application or identity access only to the specific secrets it needs, enforced by policies. It limits the blast radius if any single identity is compromised.
Secret Rotation
Automatically changing credentials on a schedule so a leaked secret is only valid briefly. Rotation dramatically reduces the value and lifespan of any stolen secret.
Dynamic Secrets
Short-lived, on-demand credentials the secrets manager generates per request (e.g., a temporary database login) and revokes automatically at expiry — so long-lived static secrets do not exist to be stolen.
Key Facts
- Hardcoded secrets are one of the most common causes of breaches — they leak through Git history, logs, and container images and are hard to fully remove.
- Encryption at rest is table stakes; the real value of a secrets manager is access control, auditing, and automated rotation.
- Dynamic, short-lived secrets are the strongest model — if there is no long-lived credential to steal, a leak is far less damaging.
Real-World Applications
Database credentials for services
Rather than baking a database password into config, a service authenticates to Vault at startup and fetches the credential — or Vault issues a unique, short-lived database login that expires automatically.
Rotating API keys
A secrets manager rotates third-party API keys on a schedule and applications always read the current value, so a leaked key is invalidated quickly without a manual scramble to update every service.
Frequently Asked Questions
Why is hardcoding secrets in code dangerous?
Secrets embedded in source code, config files, or container images leak very easily. Once committed to Git they live in history forever, even if later removed; they get printed in logs and error messages; and they are baked into shared images anyone can inspect. A single exposed database password or API key can compromise your entire system, which is why secrets should never be hardcoded and instead retrieved from a secrets manager at runtime.
What is a secrets manager?
A secrets manager is a dedicated system — such as HashiCorp Vault, AWS Secrets Manager, or a cloud KMS — that centrally stores sensitive credentials encrypted at rest, controls who can access each secret through fine-grained policies, logs every access for auditing, and can rotate secrets automatically. Applications authenticate to it and fetch the secrets they need at runtime, so credentials never live in code, config, or images.
What are dynamic secrets?
Dynamic secrets are short-lived credentials that a secrets manager generates on demand, per request, rather than storing a single long-lived secret. For example, instead of a permanent database password, Vault can create a unique database login when a service needs one and automatically revoke it when it expires. Because there is no persistent secret to steal, dynamic secrets dramatically reduce the risk and impact of a leak.
Why is secret rotation important?
Rotation means regularly changing credentials so that any leaked secret is only valid for a short time. Even with strong storage and access controls, secrets can occasionally leak through logs, misconfiguration, or a compromised system. Automatic rotation limits the window an attacker can use a stolen credential, and combined with short-lived dynamic secrets it minimises the damage a single leak can cause.