Cybersecurity glossary
What is a Secrets Manager?
Learn what a secrets manager is, how cloud vault APIs issue and rotate credentials by identity, and how it differs from Kubernetes Secrets and from secrets-management process.
Definition
A secrets manager is a managed service that stores encrypted credentials, issues them to authenticated identities over an API, records access, and often rotates values on a schedule so applications do not keep long-lived secrets in code, images, or local files.
Why secrets managers exist
Applications still need strings that are not public: database passwords, third-party API keys, webhook HMAC secrets. If those strings live in Git, Terraform state, or a shared Slack message, every copy is a standing credential.
A secrets manager is the cloud-native vault API: encrypt at rest, authorize by identity, version the value, and optionally rotate it with the downstream system. It does not replace least privilege—it makes least privilege enforceable.
How an application retrieves a secret
The workload authenticates
Instance role, pod identity, or function execution role—not a hardcoded vault password in the image.
IAM authorizes the get
A policy names the secret ARN or path. Wildcards across all secrets are a finding, not a convenience.
The service returns a version
AWSCURRENT, a numbered version, or a stage label. Apps should pin to the stage they understand.
The app caches briefly
In-memory cache with TTL reduces chatter; disk cache recreates the local-file problem.
Rotation publishes a new version
A rotation lambda or operator sets the new password on the database, then updates the manager.
What a secrets manager is for (and not for)
Third-party API keys
Vendors that cannot federate still need a stored token with rotation and owner metadata.
Database passwords
Rotation functions can flip passwords if the engine and the app support dual-use windows.
Not cloud API access
Prefer workload identity for AWS/GCP/Azure APIs instead of static access keys in the vault.
Not a config dump
Non-secret feature flags belong in config stores. Mixing them trains people to over-grant read.
Secrets manager compared with nearby stores
| Store | Strength | Limit |
|---|---|---|
| Secrets manager | IAM retrieval, versions, rotation hooks, audit of reads | App must fetch at runtime and handle version changes |
| Kubernetes Secret | Native mounts for pods | etcd copies, weaker rotation, easy RBAC over-grant |
| CI variable store | Convenient for pipelines | Broad human access, weak workload identity, easy log leaks |
| Workload identity only | No long-lived cloud key to steal | Cannot satisfy third-party APIs that only accept static tokens |
Secrets manager checklist
- Grant GetSecretValue (or equivalent) per secret to specific workload identities—never to a shared human admin role for daily use.
- Authenticate with workload identity; do not put a vault token inside the container image.
- Enable rotation where the dependency supports it, and test the reload path before the first expiry.
- Turn on secret read audit logs and alert on reads from unexpected principals.
- Keep Terraform and Helm free of plaintext values; pass ARNs, not the secret payload.
- Separate prod and non-prod vaults or prefixes so a staging role cannot read production.
- Rotate and revoke immediately when a value appears in git, tickets, or crash logs.
- Prefer identity federation for cloud APIs; use the manager for secrets you cannot eliminate.
The practical takeaway
A secrets manager is a managed vault API: encrypted storage, identity-based retrieve, versions, and rotation. It is the product; secrets management is the operating model around it.
Wire workloads to it with IAM, not with copied strings. If every function can read every secret, you have centralized the keys without reducing blast radius.
Related security terms
Secrets Management
The end-to-end discipline; a secrets manager is the usual storage and issuance product.
Kubernetes Secret
A cluster object that can cache values from a manager but is not itself a vault.
Workload Identity
How apps authenticate to the manager without embedding a vault token.
Cloud IAM
Policies that decide which identity may GetSecretValue or equivalent.
Secret Scanning
Detects values that bypassed the manager and landed in git or logs.
Frequently asked questions
What is a secrets manager in simple terms?
It is a locked API for passwords and keys. Applications prove who they are, receive the current value, and the service can change that value later without a code deploy.
How is a secrets manager different from secrets management?
Secrets management is the process: inventory, ownership, rotation, revocation. A secrets manager is a product that implements storage, IAM retrieval, audit, and often rotation jobs.
Is Parameter Store or a KMS ciphertext the same thing?
KMS encrypts blobs; you still handle distribution. Parameter stores can hold config and sometimes secrets. A secrets manager adds versioning, rotation hooks, and secret-specific IAM and logging.
Should Kubernetes use a secrets manager?
Prefer CSI or external-secrets sync from the manager, plus workload identity. Avoid copying long-lived cloud keys into etcd as the only copy.
Does putting a secret in the manager make it safe?
Only if IAM on GetSecretValue is tight, the value is not logged, and rotation actually runs. A wildcard role that can read every secret is a vault-shaped file share.
What should be rotated automatically?
Database passwords, API tokens the vendor supports, and envelope keys on a documented cadence. If the app cannot reload, rotation will cause an outage—fix the app, do not skip rotation forever.
Can I replace all secrets with workload identity?
For cloud APIs, yes, prefer identity federation. For third-party APIs and some databases, a manager still holds the credential the vendor requires.
References
Explore authoritative guidance and frameworks related to secrets manager.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.