Secrets Distribution Service  ·  View 01 of 34  ·  1 · Context and scope

System Context

The workloads that consume credentials, the people who govern them, the upstreams that accept them, and the authorities the platform leans on without owning.

Editable source SVG draw.io All views
Workloads that consume credentials Services, jobs, CI runners 40,000 instances Legacy processes file or proxy only People Service team Secret owner Security responder Platform SRE Upstreams it serves, and the record it feeds Databases PostgreSQL · MariaDB · MongoDB Brokers, object store, APIs RabbitMQ · Kafka · Ceph RGW Partner APIs keys it cannot mint Records archive Object Lock · 7 y Secrets Distribution Service attest · issue · expire · revoke Authorities it relies on without owning Kubernetes API servers token signer HSMs and offline root key ceremony Corporate IdP operators only attest · fetch tmpfs file grants rotation revoke operates accounts users · tokens verify key audit TokenReview seal OIDC Secrets Distribution Service — System Context External / third party Person or role Data store Security / platform synchronous event / async batch v 1.0 · owner Security Platform Architecture · date 2026-09

Decisions

  • The boundary is distribution, not the dependency. PostgreSQL still checks the password and the partner still validates the key; the platform's authority ends at whatever an upstream can be told to create or delete.
  • The Kubernetes API servers and the HSMs sit outside. The first signs the tokens that start the chain of trust; the second holds the keys that end it. The platform consumes both and can leak neither.
  • The records archive belongs to the records team, not to the platform. Evidence that the platform's own operators could edit is not evidence.

Assumptions

  • A few thousand services, 40,000 workload instances, three environments, two sites; 3,200 custodial secrets, 700 brokered roles and 14 upstream providers. All figures are the requirement's stated assumptions.
  • The requirement targets Google Cloud. This design solves the same problem on hardware the organisation owns with open-source software only; the mapping is in the README.

Deliberately out

  • Human sign-in to applications, TLS certificates for services (the mesh's job), code-signing policy, and the upstreams' own account models. The platform integrates with each and owns none.
All views High-Level Architecture  ▶
Solution Architecture v1.0 · Security Platform Architecture · 2026-09 · 34 views · open source, fully on-premises01-system-context