CoursesAdvanced cloud securityEncryption, keys & secrets

Secrets managers & rotation across clouds

Managed secrets, rotation, and a multi-cloud strategy.

Advanced30 min · lesson 9 of 15

A secret is not just an encrypted config value; it is a value with a lifecycle — issued, scoped, rotated, revoked, and audited on every read. A managed secrets service turns credentials from files you copy into governed resources you request at runtime, which is what makes rotation and least-privilege access practical across a fleet.

A managed secret vs a config value

Compared with a KMS-encrypted file, a secrets manager adds the operational machinery: fine-grained IAM on each secret, automatic rotation on a schedule, versioning so a rotation can roll forward or back, and an audit event on every retrieval. The application fetches the secret at startup (or per use) over an IAM-authenticated call, so nothing sensitive ships in the image or the environment definition, and access can be revoked centrally without redeploying anything.

fetch at runtime, rotate on a schedule
# App reads the secret at startup via its instance/workload identity — no secret
# in the image, the env file, or the repo. Every read is logged.
DB_URL=$(aws secretsmanager get-secret-value \
--secret-id prod/api/db --query SecretString --output text)
# Rotation is owned by the manager: a rotation function creates a NEW credential
# on the backend, tests it, then promotes it (AWSCURRENT) and retires the old one.
aws secretsmanager rotate-secret --secret-id prod/api/db \
--rotation-lambda-arn arn:aws:lambda:eu-west-1:222222222222:function:rotate-db \
--rotation-rules AutomaticallyAfterDays=30

A multi-cloud strategy

Across clouds you choose between each provider native manager (deep IAM integration, easy rotation, but per-cloud) and a central platform like Vault (one control plane, dynamic secrets, but you run it). A common pattern is central issuance with cloud-native distribution: Vault mints dynamic credentials while the External Secrets Operator syncs them into each cluster or cloud manager. Whatever the topology, keep the same invariants — short lifetimes, per-workload scope, rotation, and an audit trail on every access.

Runtime secret retrieval
1workload identity
no static secret to present
2IAM-authenticated request
to the secrets manager
3scoped secret returned
this workload, this secret only
4rotation refreshes it
consumers re-read on a cadence
The secret becomes a governed resource: requested by identity, scoped, rotated, and logged — not a value copied into config.
Rotation without refresh is an outage
Rotating a secret the consumers never re-read either breaks them (old credential revoked) or defeats the point (they keep using the stale value). Use the dual-secret overlap pattern — keep the old and new valid together for longer than the longest cache or lease — and make sure every consumer refreshes within that window before you retire the old credential.