Scaling
What runs when IAM stops answering?
On August 20 Google Cloud's us-west1 lost identity and access management for 76 minutes and key management for 43. A briefing on the dependency nobody draws.
By TIS Partners · · 1 min
On the afternoon of August 20, Google Cloud's status page recorded a regional incident in us-west1 spanning two dozen products: Identity and Access Management degraded for 1 hour 16 minutes, Cloud Key Management Service for 43, Compute Engine and Kubernetes Engine for 1 hour 17, Cloud SQL for 1 hour 28. The compute numbers get quoted. The identity number is the one we would put in the review.
Is identity on your load path?
Usually, and usually undrawn. A service that mints a token per request, validates a caller's credential against the provider on each call, or fetches an envelope key from KMS for each write has placed a control plane inside its data path. The load path diagram rarely shows it because the call is small, fast and invisible until the afternoon it is not.
What would have to be true to survive 76 minutes?
Three things, and teams typically have one. Credentials cached with a lifetime longer than the outage, and refreshed before expiry rather than at it. Data-encryption keys held in memory after the first unwrap, so KMS is consulted at startup and not per write. And no authorization decision that requires a live policy lookup for steady-state traffic. Each has a cost: a longer credential lifetime widens the window a leaked token is useful, which is the tradeoff the security review will name, correctly.
The recommendation fits on a line. List the steady-state paths that mint, validate or unwrap per request, and write the token and key lifetimes next to them. Whatever is shorter than an hour and 16 minutes is a finding.