Service Mesh Platform  ·  View 29 of 31  ·  7 · Assurance

Security — Trust Zones

Five zones by exposure, what is allowed to cross between them, and what a compromise in each can reach.

Editable source SVG draw.io All views
Outside the mesh External APIs declared hosts Legacy VM job no identity Boundary Egress gateway TLS origination Strict namespaces checkout default deny ledger allow by identity Mesh control istiod config · no keys SPIRE server cluster CA Key custody OpenBao PKI intermediates Offline root HSM · ceremony TLS · allowlist declared host plaintext refused xDS over mTLS CA renewal Security — Trust Zones and What Crosses Them External / third party Risk / gap Interface / broker Application we own Security / platform synchronous failure / alternate event / async No proxy holds a key that proves any identity but its own. istiod holds no signing key at all; the only in-cluster CA lives 7 days. v 1.0 · owner Security Architecture · date 2026-09

Decisions

  • No proxy holds a credential for any identity but its own workload's. A compromised proxy impersonates exactly one service, and only until its certificate expires.
  • istiod holds no signing key. Compromising the configuration compiler lets an attacker change routes and policy, which is audited and reverted; it does not let them mint identities.
  • Proxies accept configuration only from an istiod whose certificate chains to the mesh root and carries the control plane's SPIFFE ID.

Separation of duties

  • Routing, authorisation and identity live in three repositories with three owner groups. Each has an Argo CD project that can create only its own resource kinds, so one team cannot change the others' configuration.

Residual risks

  • A workload in a permissive namespace can still receive plaintext. The plaintext report makes that visible; closing it is the migration in view 04, not a platform switch.