Container Registry and Software Supply Chain Platform  ·  View 04 of 33  ·  2 · Structure

Layered Architecture

What depends on what, and why no layer calls upward.

Editable source SVG draw.io All views
Consumption kubelet + containerd Argo CD Developer CLI Ops Console Enforcement Admission Controller Evidence Sync Local Caches Policy OPA Evaluator Bundle Builder Exception Registry Dry-Run Engine Intelligence Scanner Pool Advisory Reconciler Re-Evaluator Impact Analyser Evidence Attestation Service Verifier Component Indexer Findings Service Artifact Harbor Core Distribution Proxy Cache Lifecycle and GC Data MinIO PostgreSQL ClickHouse Kafka Redis Platform Keycloak SPIRE Vault + HSM Fulcio + Rekor Audit Ledger AdmissionReview in-process cached input subscribe signed result referrers insert blobs trust roots Container Supply Chain — Layered Architecture External / third party Application we own Security / platform Interface / broker Data store Queue / topic synchronous event / async Dependencies point downward only. Evidence reaches the enforcement plane by subscription, not by an upward call. v 1.0 · owner Enterprise Architecture · date 2026-09

The layering rule

  • Dependencies point downward only; the evidence plane never calls the enforcement plane
  • Evidence reaches the edge by subscription to Kafka, so the arrow points down to the data layer, not up to the consumer
  • Intelligence sits above evidence because it reads the evidence API; it is a client, not a peer

Deliberately omitted

  • Replica counts and technology versions — see the container view
  • Every interface — see the integration catalogue

Risk

  • The platform layer is a shared dependency for all seven layers above it; a Keycloak outage degrades push but not verification
  • Verification depends on trust roots, not on the key service — that is deliberate, and it is what keeps act 6's key-service failure survivable