The trust boundaries — where the system trusts and does not

A trust boundary is the line where one component’s identity ends and another’s begins. Crossing it means a packet signed by A is verified by B and then re-signed by B for the next leg. A system with no boundaries has no identities; a system with unsigned boundaries has no verification. The reference architecture has seven boundaries, each with a verification mechanism. A boundary whose verification is missing is an impersonation path.

The seven boundaries

flowchart LR
    subgraph L["Laptop (untrusted)"]
        E["Engineer"]
    end
    subgraph S["Source plane"]
        R["Git repo"]
    end
    E -->|"B1: SSH + GPG"| R
    R -->|"B2: webhook + OIDC"| CI["CI plane"]
    CI -->|"B3: cosign sign"| A["Artifact plane"]
    A -->|"B4: digest + sig verify"| D["Deploy plane"]
    D -->|"B5: kube API + RBAC + IRSA"| K["Cluster"]
    K -->|"B6: mTLS"| X["Cross-cluster replication"]
    K -->|"B7: mTLS pull"| O["Observability plane"]

The seven boundaries, in order:

• B1: laptop to source repo. SSH key authenticates the push; GPG key signs the commit. Verification is signature check on receive.
• B2: source repo to CI. Webhook carries an OIDC token scoped to the workflow identity; runner exchanges it for short-lived cloud credentials.
• B3: CI to registry. Image is cosign-signed; provenance and SBOM attached as OCI artefacts and re-signed.
• B4: registry to deployer. Deployer pulls by digest and verifies cosign signature against a trusted root.
• B5: deployer to cluster. Controller authenticates to the kube-apiserver with a workload-identity credential; RBAC enforces at the namespace.
• B6: cluster to cluster. Replication and backup cross cluster boundaries over mTLS; receiving cluster verifies the issuer.
• B7: cluster to observability. Logs, metrics, traces pulled over mTLS; the audit trail is reconstructed from receipts, not pushed.

What a boundary protects

• B1 against a network attacker between laptop and repo.
• B2 against a workflow that is not the one reviewed.
• B3 against a tampered image.
• B4 against a registry that serves an artefact not produced by the claimed workflow.
• B5 against a controller with too much privilege.
• B6 against a passive observer of replication.
• B7 against an attacker who reads or forges observability data.

Boundary vs edge

An edge is a wire; a boundary is a verification step on that wire. Every boundary has three properties:

1. Identity on each side. Each component has a distinct identity. Sharing identities collapses the boundary.
2. Signed handoff. The crossing party produces a signed artefact; the receiver verifies before trusting.
3. Re-signing on the other side. The receiver does not propagate the sender’s signature as its own authority.

A boundary missing any of the three exists in the diagram but not in practice.

Production discipline

1. Pin SSH host keys. A laptop whose known_hosts is empty trusts any network.
2. Sign every commit and tag. The receiver verifies; the sender signs.
3. Verify signatures on pull, not on push. A push that is signed but a pull that does not verify is a boundary that disappears at read time.

Cross-course references

• This course, Part LXIV (Auditability) - the chain that walks these boundaries.
• This course, Part XLVII (Signing) - the keys used at B1, B3, and B4.
• Linux for Production Sysadmins - Part XII covers the apt/dnf analogue of B1.

Quiz