Cloud secret managers & envelope encryption

AWS/GCP/Azure managers, rotation lambdas, and CMK/BYOK.

You do not always run Vault — managed cloud secret stores (AWS Secrets Manager and Parameter Store, GCP Secret Manager, Azure Key Vault) are the pragmatic default on a single cloud, and they share a common cryptographic backbone worth understanding: envelope encryption anchored in a cloud KMS. Knowing how they encrypt, rotate, and gate access lets you use them well and reason about the trust you are placing in the provider.

Envelope encryption is the shared foundation

Every cloud manager encrypts your secret with a data key, and encrypts that data key with a KMS customer master key (CMK/KMS key) that never leaves the KMS. This is envelope encryption: bulk data encrypted by a local data key, the data key protected by a central master key. The practical consequences are what matter — access to the secret requires both permission on the secret and kms:Decrypt on its key, so the KMS key policy is a second, independent gate; and using a customer-managed key (CMK) instead of the default gives you control over rotation, cross-account sharing, and the ability to revoke by disabling the key.

Managed rotation, and its sharp edge

The headline feature is built-in rotation. AWS Secrets Manager runs a rotation Lambda on a schedule that creates a new credential version, tests it, and flips the AWSCURRENT staging label to it while keeping AWSPREVIOUS valid — a dual-secret rotation you get for free. The sharp edge is the overlap window: consumers cache secrets, and if the old version is invalidated before every consumer has picked up the new one, you get an outage. The rotation window must be longer than your longest cache TTL plus deploy time (this is the dual-secret pattern, covered in depth in the rotation lesson).

$ aws secretsmanager create-secret --name prod/db \
    --kms-key-id alias/prod-secrets \   # customer-managed key = your control
    --secret-string "$(openssl rand -base64 24)"
 
$ aws secretsmanager rotate-secret --secret-id prod/db \
    --rotation-lambda-arn arn:aws:lambda:...:rotate-db \
    --rotation-rules AutomaticallyAfterDays=30
 
# read requires secretsmanager:GetSecretValue AND kms:Decrypt on alias/prod-secrets.
# always require TLS at the resource policy: aws:SecureTransport = true.

Parameter Store, and picking the right store

Not everything needs a full secrets manager. AWS Parameter Store (SecureString) is cheaper and fine for config-with-a-few-secrets and lacks native rotation; Secrets Manager adds rotation, cross-region replication, and resource policies for the credentials that need them. The decision rule: dynamic or high-value credentials that must rotate belong in the manager (or Vault); low-churn config values can live in Parameter Store. GCP Secret Manager and Azure Key Vault map to the same distinctions — versions, IAM/RBAC gating, CMK/HSM-backed keys, and (in Key Vault) a combined secrets/keys/certificates surface.