Attestation validation at pod admission has been technically possible for years and operationally rare for almost as long. The wiring is straightforward. The pod manifest references an image, the image has attestations attached, and the admission controller can fetch and verify them before allowing scheduling. The hard part has never been the wiring. The hard part has been deciding which attestations to require, what to do when they are missing, and how to keep the latency low enough that engineers do not file tickets about slow deployments.
This post is about the operational side. It assumes you have a signing infrastructure and a registry that supports referrer attestations, and it focuses on what to verify, in what order, and how to communicate failures.
Which Attestations Actually Earn Their Cost
Attestations are not free. Each one consumes registry bandwidth at admission time, adds latency to pod scheduling, and introduces a new failure mode. The set of attestations worth verifying is smaller than the set technically available.
In our estate four attestation types pay for their cost. A signing attestation that proves the image was produced by an approved build identity. A SLSA provenance attestation that names the source repository, commit, and build steps. An SBOM attestation that lists the components in the image. And a vulnerability scan attestation produced by the scanner, dated, and signed.
Other attestation types are technically interesting and operationally a wash. License attestations matter at procurement time, not at admission. Test result attestations are valuable in the build pipeline but not in the cluster. Reproducibility attestations are aspirational for most stacks. We do not block admission on those today, even where they exist.
Verification Order And Short-Circuiting
The verification chain should be ordered for fast failure. Cheap checks first. Expensive checks only after the cheap ones pass.
Our order is: signature, provenance, SBOM presence, scan freshness. Signature verification is the cheapest because it is a cryptographic operation against a small payload. If the signature does not match an approved identity, the rest of the chain is irrelevant.
Provenance verification comes next. It is also fast, but it requires fetching the attestation envelope, parsing it, and checking that the source repo and builder match the approved set. If the build came from an unrecognised builder, again, the rest is moot.
SBOM presence is a structural check. We do not verify the SBOM contents at admission time. We only confirm that one is attached and signed. The contents get analysed asynchronously by the vulnerability scanner.
Scan freshness is the last check. We require a scan attestation dated within the last fourteen days. If the most recent scan is older, we trigger a rescan and either block or warn depending on the namespace policy.
The whole chain runs in well under one second for a healthy image. For a misconfigured one, it usually fails at the signature check, which is fast.
Failing Useful
Admission failures are a UX problem. The default error message from most controllers is "image rejected by policy" with a stack trace. That message tells the engineer nothing actionable.
We standardised on a structured failure shape. Every attestation rejection produces a message with three fields. The clause that failed, in human terms. The specific value that did not match, with the expected value alongside it. And a link to the runbook entry for that clause, which describes how to remediate.
For example. "Signature verification failed. Image was signed by builder.id ghactions.example.org/legacy-runner but admission requires builder.id matching ghactions.example.org/main-runner. See runbook RB-014 for migration." The engineer reads that and knows exactly what to do.
The runbook discipline matters more than the controller. A perfectly tuned admission rejection that points at a stale runbook produces support tickets indistinguishable from a misconfigured rejection.
The Mirror Question
Attestation validation depends on attestations being available at admission time. If the attestations live on a public registry and the cluster reaches out to that registry on every pod start, you have introduced a hard dependency on someone else's uptime in your hot path.
The solution is to mirror attestations alongside images. When the registry mirror sync pulls an image, it pulls every referrer attestation as well, verifies them once at sync time, and stores them. Admission then verifies against the local mirror copy, not the upstream.
This sounds obvious and is missed often. The first time the upstream registry has a partial outage, you will discover that admission has been silently calling out to it for every pod, and that the cluster is now experiencing scheduling failures that look like a network problem but are actually a dependency problem.
Handling Missing Attestations
Not every image will have a full set of attestations on day one. Vendor images, in particular, vary widely in what they ship. The naive answer is to block any image without complete attestations. The practical answer is to grade them.
We run three classes. Class A images have full attestations from a known builder. They pass admission silently. Class B images have partial attestations, usually a signature but not provenance. They pass admission with a warning logged for the security team. Class C images have no attestations at all. They are blocked from production namespaces and admitted with an explicit waiver in development.
Vendor images get nudged toward Class A through procurement pressure and through internal mirror enrichment. When we pull a vendor image into our mirror, we generate our own SBOM and scan attestation alongside it, signed by our internal builder. This does not turn a Class C image into Class A, but it can turn it into Class B and unblock production use while we work the upstream.
Operational Hygiene
Attestation infrastructure rots without attention. Three habits keep it healthy.
Quarterly key rotation for the build identity. Rotation is a forcing function for verification. If the rotation does not break anything, the verification was probably not happening.
Negative testing on a schedule. Every quarter we deliberately push an image without a signature into a test namespace and verify that admission blocks it. If admission lets it through, something has drifted in the verification chain.
A staleness alarm. The scan attestation freshness check produces a metric. If the metric trends upward, scans are not running often enough, and the validation has degraded into a check on whether the image has ever been scanned, which is much weaker.
How Safeguard Helps
Safeguard runs the full attestation validation chain with the operational features that make it survive. The admission webhook performs signature, provenance, SBOM, and scan freshness checks against a local mirror, with sub-second latency at the pod admission path. The mirror sync collects and verifies referrer attestations once and reuses them for every admission decision, removing the dependency on upstream registries from the hot path. Failure messages follow the structured shape with clause, specific values, and runbook links, and the runbook content is editable in the same UI that holds the policies. Image grading runs continuously, surfacing Class B and Class C images in dashboards so that procurement and platform teams can drive them toward full coverage. Negative testing and key rotation hooks are built into the platform so that the verification chain stays healthy rather than slowly degrading. The result is admission-time attestation validation that is fast, operable, and trustworthy on its second year in production.