Image verification, one layer below admission

Every admission webhook you rely on has an escape hatch. Nothing scandalous about that, it is just how Kubernetes wires them up. A CNCF post on July 30 pitches a way out: move signature and attestation checking out of the API server and into the container runtime itself, via a Node Resource Interface plugin.

The pitch, in one paragraph. The Supply Chain NRI Plugin hooks CreateContainer events on the runtime (CRI-O or containerd), pulls the image reference and digest from the runtime annotations, fetches attestations from the OCI registry, and verifies them against a per-namespace policy before the container starts. It checks three artefact types: SLSA provenance, VEX documents, and VSA. If verification fails, the container does not start. The hook fires at create-time, not at image pull, so an image that has been sitting on a node for hours still gets checked before it actually runs.

Why admission is not the whole story

You already know the failure modes. The CNCF post names four. Static pods managed directly by the kubelet skip admission entirely (the mirror pod can fail, the container still runs). Anyone with direct kubelet access bypasses the API server on the way in. Misconfigured namespace selectors silently exempt whole namespaces. And an admission webhook outage forces a bad choice: cluster lockup or silent bypass.

Kyverno, OPA Gatekeeper and Sigstore Policy Controller all live at the API layer, so they all inherit those escape hatches. The layer is the problem, not the projects. Moving the check down into the runtime closes the loop: every container has to pass through the runtime, whatever path scheduled it.

The catch

Runtime-level verification is not a free lunch. You now depend on a plugin being healthy on every node, with the credentials and network path to reach the OCI registry, on every CreateContainer call. Fail open and you have compliance theatre. Fail closed and a registry blip becomes a cluster-wide launch stall. The post does not spell out what the plugin does when the registry is unreachable, or how a policy update rolls out to nodes mid-flight. You are going to want the answer to both before you enable this on anything you care about.

Verdict: the trust boundary moves in the right direction, and the four bypass paths are real. Bring your own runbook for what happens when the registry has a bad afternoon.