Enterprise Secrets Management, Compared

An API key, database password or signing token that sits in a .env file, a CI variable or a chat message has no owner, no expiry and no record of who used it. A secrets manager fixes three things at once: it stores the credential encrypted in one place, it decides which identity may read it, and it writes a log entry every time it is read or changed.

The short version: if nearly all of your workloads live in one cloud, that cloud's native service is the least work to operate. If you run across several clouds or on-premises, Vault gives you one policy language and one audit stream for all of them, at the price of running and upgrading it yourself.

Rotation limits how long a stolen credential stays useful. The hard part is changing a credential that running services depend on. Three patterns cover most cases:

• Dynamic credentials. Vault's database and cloud secrets engines create a new username and password per client, with a lease that expires on its own. Nothing long-lived exists to rotate.
• Dual secrets (alternating users). Two credentials are valid at the same time. You rotate the idle one, move clients to it, then retire the old one. AWS Secrets Manager ships this as its alternating-users rotation strategy.
• Expiry with alerts. For third-party API keys that you must regenerate by hand, set an expiry date and alert before it passes. Azure Key Vault publishes near-expiry events; Google Secret Manager publishes rotation notifications.

Set the interval by risk, not by habit. A key that can move money or read customer data deserves a shorter life than a read-only metrics token. Rotate at once whenever a credential appears in a log, a repository or a ticket.

Grant to workloads, not people. Give each service its own identity (an IAM role, a Kubernetes service account, a Vault AppRole) and let it read only the paths it needs. Humans get break-glass access that requires approval and leaves a record.

Keep reads and writes apart. The team that rotates a secret does not need to read its value, and the service that reads it should never be able to change it.

Log every read. AWS records Secrets Manager calls in CloudTrail. Google records access in Cloud Audit Logs, but data-access logging must be turned on. Azure sends Key Vault diagnostic logs to Log Analytics or a storage account. Vault writes to its audit devices and stores sensitive values as HMAC hashes. Send all of it to one place, alert on reads from new identities or unusual volumes, and review who holds access every quarter.