Artifact Signing, Provenance Attestation, and the Trusted-Registry Admission Gate
A multi-agent fleet does not run the code you wrote. It runs the code that arrived. Between the commit and the running container sit a build server, a package registry, a base image pulled from a public mirror, forty transitive dependencies, and a deploy pipeline that no single operator watched end to end. Every one of those is a place where the artifact you meant to run and the artifact that actually runs can quietly diverge.
The earlier Trust lessons secured what happens once the code is already inside the walls. Data-integrity guarantees hashed the records at rest. RBAC decided which ServiceAccount could touch which secret. Admission control governed how a credential entered a pod. All of that assumes the workload itself is the one you built. Supply-chain integrity is the discipline that earns that assumption instead of granting it for free.
The question is narrow and it is answerable: can this fleet prove that the image about to run was built by its own pipeline, from source it controls, and has not been swapped for a look-alike since. Answer it with three moves — sign the artifact at build, carry a provenance record with it, and refuse to admit anything unsigned at the cluster door. Name the third move now, because the whole lesson leans on it: the trusted-registry admission gate.
Start with what a container image actually is. Poulton describes it in Docker Deep Dive (pp. 242–243) as a set of content-addressed layers, each identified by a SHA-256 digest, assembled under a manifest that is itself digest-addressed. The tag — myimage:v2 — is a mutable pointer. The digest — myimage@sha256:9f86d0… — is immutable. A tag can be re-pushed to point at different bytes tomorrow; a digest cannot, because changing the bytes changes the digest.
So the naive integrity story is already available: pin by digest, never by tag. What digest-pinning does not tell you is who put those bytes in the registry. An attacker who compromises the registry can push malicious bytes and hand you their digest; you would pin faithfully to poison. Content addressing proves the bytes are the bytes. It does not prove the bytes are yours.
That gap is what signing closes. The Sigstore project — cosign is its container-signing tool — produces a signature over the image digest and stores it alongside the image in the registry. Verification checks the signature against a trusted public key. Now the claim is stronger: these bytes were signed by a key the fleet controls. Provenance is the third layer. A provenance attestation, in the SLSA sense, is a signed statement recording the build: which source commit, which builder, which parameters. Poulton's Kubernetes Book (pp. 226–227) frames the CI/CD pipeline as the enforcement point where this record is generated, because the pipeline is the only actor that witnesses the build first-hand.
Hold the three artifacts apart, because they do different jobs and fail differently.
The fingerprint. Costs nothing, always available, catches accidental drift — a re-pushed tag, a stale mirror. Catches no adversary who can write to the registry.
The seal. Binds the fingerprint to an identity. Catches registry compromise, provided the signing key stays out of the attacker's hands. Its whole security rests on key custody.
The birth certificate. Records the build so a policy can demand not merely signed but signed and built from the fleet's own branch by the fleet's own runner.
Now the coined move earns its name. Sign at build, verify at admit. The build pipeline is the only place with the source, the key, and first-hand knowledge of what it produced, so signing and attestation happen there and only there. The cluster is the only place every workload must pass through before it runs, so verification happens there and only there. Put verification anywhere earlier and a later hop can bypass it; put signing anywhere later and the signer is vouching for bytes it did not make.
The trusted-registry admission gate is where verify-at-admit becomes mechanical. Kubernetes: Up and Running (pp. 262–263) walks the admission flow: authenticated and authorized requests pass to admission controllers, and a validating admission webhook can reject the request outright. A signature-verification webhook sits exactly here. It reads the image reference in the incoming PodSpec, fetches the signature and attestation from the registry, checks them against the fleet's trusted key and provenance policy, and returns admit or deny. An unsigned image never becomes a running pod. The gate is not advisory. It is the wall.
Take the fleet's intake agent, fleet-intake, deployed to the agents namespace. At build time, the CI runner builds the image, pushes it, receives the digest sha256:1a2b…, then signs that digest and attaches provenance:
cosign sign --key env://COSIGN_KEY \
registry.hedronite.internal/fleet-intake@sha256:1a2b...
cosign attest --key env://COSIGN_KEY \
--predicate provenance.json --type slsaprovenance \
registry.hedronite.internal/fleet-intake@sha256:1a2b...The signing key exists as an environment secret injected into the runner and is never written to the image, the manifest, or any log. This is the two-key separation: the private signing key lives only in the build environment, the public verification key lives only in the cluster policy, and neither environment holds the other's half. The deploy manifest references the image by digest, never by tag:
spec:
containers:
- name: intake
image: registry.hedronite.internal/fleet-intake@sha256:1a2b...At admit time, the pod-creation request reaches the validating webhook — a policy controller such as Kyverno or Sigstore's policy-controller — carrying a rule scoped to the agents namespace: every image must carry a cosign signature from the fleet's public key, and every image must carry an SLSA provenance attestation whose source repository matches github.com/hedronite/fleet-intake.
latest tag → manifest pins a digest, nothing changes. Attacker pushes malicious bytes under a fresh digest and edits the manifest → bytes carry no valid signature, webhook denies. Insider signs a malicious image with a stolen build key → signature verifies, but the provenance shows an unsanctioned branch, webhook denies. Each layer catches what the layer beneath it cannot.
One honest limit. If the attacker holds the build key and can drive the sanctioned runner to build from a poisoned commit on the main branch, every check passes and the poison admits. Supply-chain integrity narrows the attack surface to the build environment itself; it does not abolish it. That is why build-key custody and the runner's source controls are the last mile, and why the audit trail from the RBAC lesson watches the signing identity as closely as any other privileged actor.
The data-integrity lesson (06-23) built the primitive this one rests on. A signature is a hash bound to a key; the checksum discipline from that lesson is the same tamper-evidence move, lifted from a data record at rest to a build artifact in transit. The admission-control lesson (05-27) built the enforcement seat: that lesson placed a validating webhook in the admission chain to govern secret injection through the External Secrets Operator, and the signature-verification webhook occupies the same seat with a different rule. One admission gate, two policies. The RBAC and audit lesson (06-24) supplies the watch: signing introduces a new privileged identity, the build key, and RBAC scopes who may write to the trusted registry while audit logging records every signature the pipeline produces.
Today's Dev lesson takes the same problem down a level, into the JavaScript and TypeScript dependency graph that lives inside the image this lesson signs. Signing the container proves the assembled artifact is yours; it says nothing about whether the forty npm packages baked into it were themselves the packages you meant. The Dev lesson treats the lockfile as the witness that pins each dependency by integrity hash, the install-script gate that refuses packages running arbitrary code at install time, and the typed provenance boundary that makes an untrusted module's shape a compile-time concern. Pin the artifact, verify the source, refuse the unverified — the same discipline at two scales.
Sign at build. Verify at admit. Pin by digest between them. The fleet that holds those three does not trust its registry, its mirrors, or its transitive dependencies; it verifies them, and it fails closed when verification fails.
Build the gate before you need it. A supply-chain attack is discovered, not prevented, in a fleet that added verification after the incident. Stand the admission webhook up while every image already passes, so the day an unsigned image appears, the wall is already there and the pod never runs. Examine the pipeline end to end and name every place the artifact changes hands. Each hand-off you cannot verify is a seam, and the seams are where the fleet lives or dies.