Your admission check verified an image by tag; what makes the node pull exactly the bytes that were verified?

## The gap Verification and execution are two separate reads of the registry. Between them sits a window, and whether anything can move in that window depends entirely on how the artifact is named. A digest is content-addressed: `sha256:9f2a...` *is* the bytes, so a second read either returns those bytes or fails. A tag is an ordinary mutable pointer in a registry's namespace. If the admission check resolves `app:1.4`, verifies a signature over the digest that resolution returned, and then admits a pod whose spec still says `app:1.4`, the kubelet performs its own resolution later. This is a time-of-check-to-time-of-use gap, and the interesting thing about it is that the verifier passed honestly — it really did verify a signed artifact. It just did not verify *the* artifact that ran. ## Who can move the tag The threat here is not usually an anonymous outsider. It is whoever can push to that repository: a compromised CI credential, a malicious insider with legitimate publish rights, a compromised registry or, quietly, a pull-through mirror. Mirrors deserve special attention because the verifier and the kubelet frequently do not read from the same place. The verifier may reach the upstream registry with one set of credentials while nodes are configured to pull through a cache. Same tag, two resolutions, no contradiction anywhere in the logs. ## What the implementations do about it **Kyverno.** `verifyImages` can mutate the image reference to the digest it verified, controlled by `mutateDigest`, and can insist the incoming reference already be a digest via `verifyDigest`. Because it mutates, the rule runs as a mutating admission step, and the admitted object carries the digest. **Sigstore policy-controller.** Its webhook can likewise resolve tags to digests for the resources it admits, so the running spec pins what was checked. **Client-side verification.** Verifying with a CLI in a pipeline is fine, and it closes nothing in the cluster by itself. Its output must feed forward: the pipeline records the digest it verified and deploys *that*, rather than deploying a tag and hoping the tag still means the same thing. ## The second-order problems Mutation solves the naming, and introduces its own ordering questions. - **Other mutating webhooks.** Anything that also rewrites the pod's containers — a sidecar injector, an image-rewriting webhook that repoints images at an internal registry — can act after the verifying webhook. Ordering between mutating webhooks is not a guarantee you should build a security control on; reinvocation exists precisely because a later mutation can invalidate an earlier decision. If an image-rewriting webhook runs after verification, the object that gets persisted may name an image nobody verified. - **Re-pulls over the lifetime of the workload.** A pod outlives its admission check. It is rescheduled, the node is replaced, the image cache is evicted. With a digest in the spec, every one of those re-pulls is checked against the same content. With a tag, each one is a fresh, unverified resolution. - **Image caches.** With a tag and a cache-friendly pull policy, a node may run a locally cached layer set that nobody ever checked. With a digest, the identity of the cached image is unambiguous. - **Non-pod paths.** Objects created by controllers, jobs spawned later, and images named in fields your policy's matcher does not cover are all ways an unverified image gets in behind a rule that looks complete. ## What to actually ask for In interviews the strongest answer states the invariant rather than the setting: **what executes must be named by content, not by a name someone else can repoint.** Two ways to get there — require digest-only references and reject tags outright, or let the verifier substitute the digest it verified — and they compose well. Requiring digests is cleaner and pushes work onto the teams writing manifests, which is why most estates start with substitution and tighten later. Then check the seams: which webhooks run after yours, which registries your nodes actually read from, and whether a re-pull six weeks from now still lands on the bytes somebody vouched for.