Every team eventually reaches the point where credentials are in too
many places: a .env on each laptop, a pinned message in Slack, a
spreadsheet called "logins", a CI variable someone set two years ago.
A cloud secret manager exists to collapse all of that into one place
that is encrypted, access-controlled and audited.
This guide explains what a cloud secret manager does, how to choose between the main options, how to roll one out without a long migration, and the one job it does not do, which is getting a secret to a human who is not inside your cloud account.
What a cloud secret manager does
A secret manager stores sensitive values and hands them to authorised identities on request. The core features are the same across providers:
- Encrypted storage at rest, with keys held in the provider's key management service, and TLS in transit.
- Identity-based access: each secret has a policy saying which users, roles or workloads may read, write or rotate it. An application authenticates with its own identity, not with a master password.
- Audit logging of every read, write and rotation, with who, what and when.
- Versioning and rotation: a new value can be staged, applications switched over, and the old version retired. Many managers rotate database credentials automatically.
- Runtime retrieval: the application fetches the secret when it starts or when it needs it, so the value is never written into code, images or config files.
A secret is anything that grants access. Configuration that merely describes behaviour, such as a port number or a feature flag, belongs in ordinary config. Mixing the two makes the secret store noisy and the config store dangerous.
How to choose one
The decision usually comes down to where your workloads run and how many clouds you are in.
| Option | Best fit | Watch for | | --- | --- | --- | | AWS Secrets Manager / Parameter Store | Workloads already on AWS, IAM identities everywhere | Per-secret pricing on Secrets Manager; Parameter Store is cheaper for plain values | | Google Secret Manager | GCP projects, Cloud Run and GKE workloads | Regional replication choices | | Azure Key Vault | Azure workloads, certificate lifecycle needs | Separate vaults per environment to keep policies simple | | HashiCorp Vault | Multi-cloud or on-prem, dynamic short-lived credentials | Operating it yourself unless you use the hosted version | | Doppler, Infisical, 1Password Secrets Automation | Small teams wanting developer-friendly sync to many platforms | Another vendor in the trust chain |
Four questions settle most choices. Does it integrate with your deployment tooling and runtime without custom glue? Can workloads authenticate to it with the identity they already have? Does it rotate the credential types you actually hold? And do its audit logs land where your security team already looks? Pricing, regions and compliance attestations come after those four.
Rolling one out without a six-month project
- Inventory and assign owners. List every secret, where it lives, what uses it, and who is responsible. The owner decides the rotation policy and the access list.
- Set up identities first. Create the roles or service accounts for each workload and environment before you move a single value. Access policies that say "this service, this environment, read only" are the whole point.
- Migrate in order of risk. Production database passwords and payment keys first, then third-party API keys, then everything else. Remove each value from code, CI variables and config files as it moves, and rotate it on the way in, because the old value has already been copied around.
- Change how applications read secrets. Replace hard-coded values and environment files with a call to the manager's SDK at startup, or inject them with the platform's native integration.
- Turn on rotation for anything the manager can rotate itself, and write a rotation function or runbook for the rest.
- Alert on the unusual. A secret read from a new identity, a spike in reads, or a read from a region you do not deploy to is worth a page.
Common mistakes are predictable: leaving the old copies in place after migration, giving a workload read access to the whole store instead of its own secrets, and logging the retrieved value in application logs.
The gap a secret manager does not fill
A secret manager is built for machines and for people inside your identity system. It is not built for the moment a credential has to reach someone outside it: a contractor who needs a temporary database password, a client receiving their first admin login, a vendor's engineer who needs a token for an afternoon, a new hire on day one before their SSO account exists.
Those handoffs happen anyway, and without a sanctioned route they happen in email and chat, which is where secret managers were supposed to get credentials out of. The sanctioned route is a one-time secret link. The value is encrypted in your browser before it is stored, the message carries only a link, the stored copy is destroyed the first time the link is opened, and the link expires on a timer if nobody opens it.
The pattern that works: the secret manager is the system of record, and the one-time link is the delivery mechanism when a human outside the system needs a value once. Generate the credential, store it in the manager, send it to the person through a one-time link, and rotate it when their access ends. Secret links vs password managers applies the same reasoning to the team password manager, and the credentials between teams guide covers the routine.
A short checklist
- Every secret has an owner, an access policy and a rotation rule.
- Workloads authenticate with their own identity, never a shared key.
- No secret exists in code, images, CI variables or chat after migration.
- Reads are logged somewhere a person actually looks.
- Humans outside the identity system receive secrets through a one-time link, not a message.
Do those five things and the secret manager stops being a product you bought and becomes the reason credentials stopped leaking.