Secrets Management in the Cloud: KMS, Secret Stores, and Rotation

Every system has secrets: database passwords, API tokens, signing keys, TLS private keys. The question is never whether you have them but where they live. In too many estates the answer is a config file, an environment variable baked into an image, or a variable in a CI job — which is to say, everywhere and nowhere, one repository clone away from an attacker. Managed key and secret services exist to give secrets a single defensible home.

Cloud secret management rests on two distinct building blocks that are easy to conflate. A key management service — AWS KMS, Azure Key Vault, GCP Cloud KMS — manages cryptographic keys and performs encryption operations so the key material never leaves the boundary. A secret store — AWS Secrets Manager, Azure Key Vault secrets, GCP Secret Manager, or HashiCorp Vault — stores the actual secret values and controls who can read them. One protects keys; the other protects credentials. You usually want both.

Envelope encryption, briefly

The pattern that ties it together is envelope encryption. Rather than encrypting data directly with a master key, the service generates a per-object data key, encrypts your data with it, then encrypts that data key with the master key held in the KMS. You store the encrypted data key alongside the ciphertext. To decrypt, you ask the KMS to unwrap the data key — an operation it will only perform for an identity your key policy permits. The master key never leaves the service, and every unwrap is an authorised, logged event.

Why a secret store beats a config file

• Access control per secret. Reading a database password becomes an IAM-gated API call, not a file read anyone on the box can perform.
• Audit trail. Every retrieval is logged, so a compromised app's access to a secret is visible after the fact — something a plaintext env var can never give you.
• Dynamic and short-lived secrets. Vault and cloud stores can mint credentials on demand that expire in minutes, so a leaked secret is worthless within the hour.
• No secrets in source or images. The app fetches secrets at runtime using its workload identity, keeping them out of repos, build logs, and container layers.

Rotation is the point people skip

A secret store is only half the value; rotation is the other half. A credential that never changes is a permanent liability — whoever copied it two years ago still has it. Managed rotation replaces the secret on a schedule and updates the systems that consume it, so exposure has a shelf life. The hard part is not the rotation mechanism but the discovery: you cannot rotate the API key hard-coded in a script nobody remembers, and unrotated static keys remain one of the most reliable ways attackers persist in a cloud account.

• Automate rotation and prove it happens. Short rotation windows for high-value secrets; alert when a secret's age crosses a threshold.
• Lock down key policies. Grant Decrypt and Encrypt to the specific workloads that need them, and separate key administrators from key users.
• Scan for leaked and embedded secrets. Pre-commit and repository scanning catches the plaintext credential before it ships; find and migrate the ones already out there.
• Prefer workload identity over static keys wherever the platform supports it, eliminating the long-lived secret entirely.

Managed KMS and secret stores turn secrets from an unbounded, invisible sprawl into a governed, auditable resource. But the store only protects the secrets you put in it. The dangerous credential is the one still sitting in a forgotten script or a stale environment variable — and you can't rotate, or defend, what you haven't discovered.