Distributed Job Scheduler  ·  View 18 of 20  ·  Assurance

Security Trust Zones

Five zones, and the two guards that carry most of the risk.

Editable source SVG draw.io All views
Internet — untrusted Tenant engineer Tenant HTTP target Forged callback Perimeter Load balancer TLS termination Edge protection OIDC verification Callback verifier signature + window Control zone — authorship and privilege Management API Role check author ǀ policy ǀ read Target ownership check SSRF guard Audit writer Fire zone — no tenant request reaches here Timing plane Dispatch plane Per-attempt token attempt lifetime Dispatch signer Data zone Registry + ledger payload encrypted Per-tenant keys Audit store immutable 7 y HTTPS token authenticated authorise verify target write version append claim, commit decrypt rejected signed dispatch Security — Trust Zones and What Crosses Them Person or role External / third party Risk / gap Interface / broker Security / platform Application we own Data store synchronous event / async failure / alternate Three guards carry most of the risk: the target ownership check that stops a schedule becoming an SSRF primitive, the privilege split that keeps backfill away from authorship, and the callback verifier. The monitoring and audit fan-out from every zone is omitted. v 1.0 · owner Platform Architecture · date 2026-10

Decisions

  • Target ownership is verified at definition time and again at dispatch time. Without that, a schedule is a server-side request-forgery primitive with a built-in timer and a retry budget (ADR-14).
  • No tenant request reaches the fire zone. The timing and dispatch planes are reachable only from inside the perimeter (ADR-14).
  • Backfill, horizon extension and quota change are separate grants from authorship, because each converts a scheduling mistake into multiplied real work (ADR-15).

Assumptions

  • Dispatch credentials are minted per attempt with a lifetime no longer than the attempt timeout, so a captured dispatch buys one trigger for one timeout.
  • Outcome callbacks are signed and replay-resistant within a short window; a stale signature is rejected rather than logged.

Risks

  • Domain verification is a point-in-time check. A target that is legitimately owned at definition time and later reassigned is the residual, mitigated by re-verification at dispatch and nothing stronger.
◀  Trigger Lifecycle All views Identity and Privilege Flow  ▶
Solution Architecture v1.0 · Google Cloud · Platform Architecture · 2026-10 · 20 views · 16 architecture decision records18-security-trust-zones