Cloud secret managers, briefly

AWS/GCP/Azure managers without the deep dive.

In short. Cloud providers ship managed secret stores: AWS Secrets Manager and SSM Parameter Store, GCP Secret Manager, Azure Key Vault.

Cloud providers ship managed secret stores: AWS Secrets Manager and SSM Parameter Store, GCP Secret Manager, Azure Key Vault. They encrypt with cloud KMS, integrate with IAM, and often offer rotation hooks. For teams already deep in one cloud, they can be the right default before — or instead of — running Vault.

This lesson is a map, not a deep dive. You will learn what they give you (IAM-gated reads, audit via cloud trails, optional rotation) and what they do not (multi-cloud uniformity, rich dynamic database engines like Vault's, or policy as expressive as Rego). Choose deliberately.

Common shape

Create a secret, grant a role permission to GetSecretValue / equivalent, read at runtime with SDK or CSI driver, audit who read. Prefer IAM roles for workloads over embedding long-lived cloud keys that fetch other secrets — otherwise you only moved the problem one step.

# AWS example shape (lab account)
aws secretsmanager create-secret --name app/db --secret-string '{"user":"app","password":"…}'
aws secretsmanager get-secret-value --secret-id app/db --query SecretString --output text | head -c 20; echo …

{"user":"app","pass…
# SUCCESS — IAM-gated read path

Pitfalls

Resource policies that allow * principals, secrets mirrored into env in plain Deployment YAML, and rotation jobs that update the store but not the app all recreate classic failures. Encryption at rest is table stakes — access policy and delivery path decide outcomes.

Going deeper

Cross-account access to secrets needs resource policies plus IAM — missing either side fails closed or, worse, is opened with * to make a demo work and never tightened. Prefer organizing secrets by app and environment path prefixes with separate KMS keys for prod.

Rotation Lambdas must update every consumer path, including secondary regions and disaster-recovery stacks. Test rotation in non-prod by forcing a rotate and watching error budgets. Partial rotation is worse than an honest stale secret with a known owner.

CSI drivers and External Secrets Operator make cloud managers feel like Kubernetes-native storage. Remember the value still materializes as a Secret object unless you use sync strategies that avoid durable API storage. Design for etcd exposure.

Try this

In a cloud lab, create a secret, grant only one role read access, and prove a second role fails.

aws secretsmanager get-secret-value --secret-id app/db
# as a role without permission:
aws secretsmanager get-secret-value --secret-id app/db || true

… SecretString …
An error occurred (AccessDeniedException) …
# SUCCESS — IAM deny works

Takeaway

Cloud secret managers are solid defaults inside one cloud when IAM and delivery are done right. They do not absolve you from rotation, scanning, or least privilege.

Next: rotation habits that work without heroics.

Related