Signature verification can be staffed at only one choke point across forty clusters — which do you pick?

## The question behind the question Asked with a staffing constraint, this is not really about cryptography — it is about **who controls the control**, and about what you can honestly claim to an auditor or a customer. Three properties decide it: coverage (what population passes through this seat), authority (can the constrained party remove it), and cost (feedback quality, and what the seat puts in your availability path). ## Why the pipeline gate loses as the mandatory seat In a self-service platform, pipeline definitions live with the teams. That makes a gate there structurally advisory: - **The constrained party owns it.** A team can fork the shared template, pin an older version of it, or simply add a step that bypasses it. Not usually maliciously — under deadline pressure, because it was failing. - **Its absence is silent.** A gate that did not run produces no signal. You would have to build a separate control that audits every pipeline for the presence of the gate, at which point you are maintaining two controls to get one. - **It cannot see non-pipeline creation.** Operators install their own agents; platform components inject sidecars; a vendor chart brings images nobody in your organisation ever named. These never traverse a build pipeline of yours, so a gate covers none of them. A gate remains genuinely valuable — it catches ordinary mistakes early, cheaply, and tells the right person — but as the *only* mandatory control it lets you claim only that the paved road is clean. ## Why admission wins on the properties that matter It sits on the path that everything which starts must traverse, regardless of origin, and it is operated by the platform team rather than by the teams it constrains. That is separation of duties expressed as topology: the enforcement point is outside the control of the party it governs. It also produces the artefact you need for an external claim — a denial record for anything that failed, and, with the right policy, a demonstrable statement about the population of workloads rather than about the population of pipeline runs. ## What you are accepting, stated honestly A principal-level answer names the costs rather than pretending they are small: - **Feedback moves late and sideways.** A denial at merge time reaches the author with the change in front of them. A denial at deploy time reaches whoever is deploying, possibly during a release window, in the vocabulary of the policy engine. Mitigate by making denial messages name the failing image and the concrete remediation, and by routing them to the owning team rather than to the platform on-call. - **Build context has to be plumbed.** The seat sees an image reference; policies about where a build came from require that context to travel as signed attestations bound to the digest. That is a real project, not a policy line. - **You take an availability dependency.** Workload creation now depends on the check and on the material it needs. That argues for local, replicated verification material and for verifying expensive things earlier and handing this seat a cheap local decision. - **Forty clusters means forty places to drift.** The realistic long-run failure is not an attacker defeating the check; it is one cluster where it was never installed or was quietly disabled. Treat presence-and-enforcing as a continuously verified inventory property of every cluster, alarmed like any other production invariant, and expect that to be more of your operational effort than the policy itself. ## The estate where this answer changes If part of the estate is a managed container service or a hosted function platform, there is no creation hook you can occupy at all. The only seat left is the deploy API call your automation makes — which is a pipeline-shaped control again, with all the authority weaknesses above. There you compensate on the identity side: very few principals may call deploy, those principals are automation you control rather than humans, and the deploy path itself performs the verification. You should also be explicit that the provider's own image-pull path is invisible to you, so what you can attest is that you only ever asked for verified artifacts — not that only verified artifacts ran. Saying that plainly, rather than overclaiming, is the difference between a defensible control narrative and one that falls apart under audit. ## The one-line version Put the mandatory check where the thing that would be refused cannot route around it and the constrained party cannot switch it off; keep the earlier check as feedback, not as the claim; and spend the saved effort proving the mandatory check is on everywhere rather than making it cleverer.