Distributed Lock Service  ·  View 24 of 26  ·  7 · Assurance

Security — Trust Zones

Five zones, a labelled credential at every crossing, and write access to the lock log held by exactly two components.

Editable source SVG draw.io All views
Workload and operator networks Client library SVID per pod Runaway acquirer Operator Access Envoy fan-in per-identity limit Keycloak MFA Coordination Lock arbiter prefix grants Admin API two-person rule Consensus · restricted Lock log client-cert RBAC Disk encryption LUKS + Tang Evidence · append-only Audit tailer read-only cert Audit archive object lock mTLS throttled OIDC mTLS JWT TLS watch delete-only Security — Trust Zones Application we own Risk / gap Person or role Interface / broker Security / platform Data store synchronous failure / alternate No identity outside Coordination holds an etcd write credential. Tokens never appear in logs, traces or errors. v 1.0 · owner Security Architecture · date 2026-09

Decisions

  • Every workload authenticates with an X.509 SVID from SPIRE over mTLS. Sessions and holds are bound to the SPIFFE ID, so release and renewal by any other identity are refused by the arbiter.
  • Authorisation is a prefix grant: this SPIFFE ID may lock keys under this namespace and path. Grants live in the class registry and are reviewed in the same pull request as the class.
  • etcd uses client-certificate RBAC. The arbiter's role writes /l and /q; the Admin API's role may only delete under /l and write /sys/force; the tailer's role is read-only. No human credential can write the lock log.

Denial of service by locking

  • Acquiring a lock can halt everything behind it. Envoy applies a per-identity local rate limit and the arbiter enforces per-namespace quotas on held leases and operation rate, returning a distinct quota error rather than degrading the cluster.

Isolation

  • A caller probing another namespace gets the same error, in constant time, whether the key exists or not. Authorisation is evaluated before any etcd read.