Chaos Engineering Platform  ·  View 21 of 21  ·  Assurance

Identity Flow — Who Proves What

Eighteen messages before a fault can exist, ending with the agent verifying its own permission.

Editable source SVG draw.io All views
Service owner Identity provider Platform API Service catalogue Lease issuer Cloud KMS Injection agent 1. authenticate 2. OIDC token 3. start run + token 4. verify token 5. owns this service? 6. owner + tier 1 7. approver required 8. approval attached 9. issue for targets + class 10. sign claim 11. signature 12. workload identity 13. cluster-scoped token 14. fetch lease 15. lease, 15 s, this target only 17. renew every 5 s 18. refuse after abort Identity Flow — Who Proves What Before a Fault Exists The agent verifies the lease itself. A forged or out-of-scope lease is refused in the data plane, not upstream. v 1.0 · owner Reliability Architecture · date 2026-09

Decisions

  • The agent verifies the lease signature and scope itself. A forged or out-of-scope lease is refused in the data plane, not upstream, so a compromised control plane cannot widen a blast radius.
  • Ownership is resolved from the service catalogue at run time, not cached in the platform, so a team's boundary changing takes effect on the next run.
  • The lease issuer refuses renewal after an abort. Refusal, not revocation, is how permission ends.

Assumptions

  • OIDC via the organisation's identity provider for humans; workload identity for agents; Cloud KMS for lease signing.
  • Separation of duties: the author of a definition cannot be its sole approver.

What is not drawn

  • Key rotation and the signing key's own lifecycle follow the platform's standard KMS pattern and are omitted; they do not change this flow.
◀  Security — Trust Zones All views
Solution Architecture v1.0 · Google Cloud · Reliability Architecture · 2026-09 · 21 views · 16 architecture decision records21-identity-and-lease-issuance