Secret Manager & rotation

Per-secret IAM, runtime fetch, overlap rotation.

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

Secrets as governed resources

Secret Manager gives each secret its own IAM, CMEK encryption, immutable versions, and an audit log entry on every access. Workloads fetch the secret at runtime through their attached service-account identity, so nothing sensitive ships in the image or the deployment manifest, and access can be revoked centrally without a redeploy. Grant roles/secretmanager.secretAccessor on the specific secret, not project-wide, so each workload reaches only the secrets it needs.

# Create a secret and grant access to ONE workload's SA on THAT secret only.
echo -n "$DB_PASSWORD" | gcloud secrets create prod-db --data-file=-
gcloud secrets add-iam-policy-binding prod-db \
  --member="serviceAccount:[email protected]" \
  --role="roles/secretmanager.secretAccessor"
 
# The app reads it at startup via its identity — nothing baked into the image:
DB_PW=$(gcloud secrets versions access latest --secret=prod-db)

Rotation with overlap

Secret Manager supports scheduled rotation via a Pub/Sub notification that triggers your rotation function to create a new version. The critical discipline is overlap: keep the old and new versions both valid longer than the longest consumer cache or connection lifetime, confirm every consumer has refreshed to the new version, and only then disable the old one. Rotating a secret that consumers never re-read either breaks them or defeats the purpose.