What does an image verification gate in CI never see that an admission-time check does?

## The two seats have different shapes, not different strengths The interesting property of a verification choke point is not how strong its cryptography is — all three seats can check the same signature with the same rigour. It is **what population of artifacts passes through it**, and **what facts are available at that moment**. A CI gate and an admission check differ on both axes, in opposite directions. ## What a CI gate cannot see A gate inside a pipeline covers exactly the artifacts that traverse that pipeline. Everything else is invisible to it: - **Direct application.** Anyone with credentials can apply a workload manifest from a laptop. It never touched a pipeline, so the gate never ran. - **In-cluster creators.** Controllers and operators create workloads themselves. An operator installs its own agent DaemonSet; a mutating step injects a sidecar; a chart from a vendor embeds images the chart's consumer never named. None of those image references appeared in your pipeline's inputs. - **The forked template.** In a self-service platform, the pipeline definition usually lives in the team's own repository. A team that copies the shared template and removes the gate has removed the control, and the gate cannot report its own absence. - **Time-of-check versus time-of-use.** A gate evaluates a reference at gate time. If the deployed reference is a mutable tag, the content that starts later can differ from the content that was verified. Pinning the deploy to the exact digest that was verified closes this, but that is a property of the manifest, not of the gate. - **Everything after the gate.** A promotion gate says the artifact was fit to promote. It says nothing about whether the thing that eventually ran is that artifact. The honest summary: a CI gate measures **pipeline hygiene**. It is a good control over the paved road and a null control over everything beside it. ## What an admission check cannot see Admission has the coverage property the gate lacks — it sits where workload objects are created, so it evaluates the union of everything that tries to start, whatever produced it. Its blind spots are elsewhere: - **Build context.** At admission you have an image reference, the workload spec, and whatever is reachable in the registry. You do not have the source revision, the reviewing human, the build inputs or the pipeline identity — unless someone carried those forward as signed attestations that the check knows how to fetch and evaluate. Policies that depend on build facts require that plumbing to exist. - **Anything not created through the path it hooks.** A check bound to workload creation evaluates workload creation. Processes started outside that path — a container the node's own agent starts, a process on the host — are outside its reach. - **The already-admitted.** Admission is an event, not a continuous evaluation. A workload admitted before a policy existed keeps running under the old rules until something makes it be created again. Tightening a policy therefore has a delayed, uneven effect across the estate. - **Intent and authorship.** A denial at admission surfaces to whoever is deploying, at deploy time, in machine language. The person who introduced the bad image may be someone else, days earlier. ## Why this makes them complementary rather than redundant Because the populations differ, running both is not doing the same work twice: - The **CI gate** gives cheap, early, well-addressed feedback to the person who caused the problem, with build context in hand, while the change is still cheap to fix. - The **admission check** gives coverage you can actually claim, because it does not depend on anyone routing their work through a particular pipeline. A useful framing for interviews: the pipeline gate is where you catch mistakes; the admission check is where you catch **bypass**. Mistakes are the common case and bypass is the dangerous one, which is why an estate forced to pick one mandatory seat picks the one closest to execution. ## The pull-time seat, briefly A policy in the container runtime at pull time is closer still to execution and catches even workloads created outside the orchestrator's object path. Its cost is that it is per-host: the policy and its trust material must be present and current on every node, its decisions are hard to observe centrally, and a host with a stale or edited policy is a silent hole. It becomes the interesting seat when there is no orchestrator control plane in the path at all. ## A concrete coverage test When someone claims verification is enforced, ask which of these would be refused: an image applied by hand; a sidecar injected by a platform component; a DaemonSet from a vendor chart; a pod rescheduled onto a new node an hour after the gate ran. A CI gate refuses none of them. That question, rather than a description of the cryptography, is what separates a real answer here.