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

Authorisation at the Destination

One POST from checkout to ledger, showing the order the inbound proxy evaluates identity, deny rules, allow rules and a dry-run rule.

Editable source SVG draw.io All views
checkout app checkout proxy ledger proxy ledger app OTel collector 1. POST /refunds 2. mTLS · SVID c07/ns/shop/sa/checkout 3. chain valid · SAN in expected set 4. deny rules first: none match 5. allow rule matches peer, POST, path 6. dry-run rule v2: would deny 7. shadow denial, no header values 8. forward · peer identity header 9. 201 10. 201 11. 201 Authorisation at the Destination — Enforced and Dry-Run Rules Together No step leaves the ledger proxy. The dry-run rule is compiled alongside the enforced one and changes nothing but a log line. v 1.0 · owner Security Architecture · date 2026-09

Decisions

  • Deny rules are evaluated before allow rules, so a deny added in an emergency cannot be overridden by an old allow.
  • A service in strict mode with no allow policy denies everything. The namespace onboarding change creates that default; a team writes explicit allows before traffic flows.
  • Dry-run rules are compiled beside enforced rules and change nothing except a log line. Validation happens against live traffic, not a test fixture.

Targets

  • Decision p99 ≤ 0.2 ms in-proxy. No network call in the common case.

Opt-in, later

  • External authorisation (Envoy ext_authz to OPA) is Phase 3 and per service. Each service that uses it declares a latency budget and whether it fails open or closed, and the declaration is reviewed with the policy.