How do you scope an enforcement exception for an unsigned vendor agent that must run cluster-wide?

## What the exception is really admitting Every enforcement rollout hits the same wall: some software you must run is not built by you and is not signed in a way you can verify. A monitoring or observability agent is the classic case, because it is exactly the workload with the widest reach — deployed to every node, granted read across the cluster, and often able to see mounted secrets, node filesystems, and process arguments. So the exception is not "one unsigned image". It is "a third party's build pipeline is inside my trust boundary, at the point of highest privilege". Naming that is the first half of a good answer, because it sets the size of the compensating controls: the asset at risk is credentials and keys, not merely the availability of the agent. ## Scope along every available axis A carve-out should be as small as the enforcement point can express. In descending order of looseness: | Scope | What it exempts | | --- | --- | | Unsigned images allowed | Everything. Not an exception, an off switch. | | Namespace only | Every image any team ever deploys into that namespace. | | Vendor's registry | Every product that vendor ships, including ones you never evaluated. | | Registry + repository | That one image stream, any version, including a future compromised one. | | Registry + repository + digest | Exactly the bytes you reviewed. | Combine the axes rather than choosing one: the vendor's registry **and** that repository **and**, where the update cadence allows it, the specific digest, restricted to the namespaces that genuinely run the agent — which for a per-node agent is usually one, not "cluster-wide" in the policy sense even though the workload runs everywhere. **The digest tradeoff is the real judgment call.** Pinning to a digest is the tightest scope available and it means every vendor update requires a deliberate change. That is a feature if you want each version reviewed; it is a liability if the agent auto-updates or ships security fixes weekly and the change never gets made, because the exception then quietly incentivises running an outdated agent. Pick according to who owns the upgrade and how fast the vendor moves, and say which you chose and why. ## Compensating controls The exception removes a check, so put something back: - **Mirror and re-sign.** Pull the vendor image into your own registry and sign that copy with your own key. This does not make the vendor's build trustworthy — it cannot — but it converts an unverifiable artifact into one your normal policy verifies, gives you a fixed record of exactly which bytes you admitted, and means a change upstream cannot silently become a change in your cluster. It also collapses the exception from "skip verification" to "verify against our own attestation", which is a materially different thing to explain in an audit. - **Reduce what the exception can cost you.** Review the agent's actual permissions against what it needs, restrict host access where the product supports it, and treat its service-account token as a high-value credential. If a compromised agent build would give an attacker cluster-wide secret reads, that is the risk you are accepting and it should be written down. - **Detect what you can no longer prevent.** Monitor for the image digest changing outside your mirroring process, and alert on it. A missing preventive control should be paired with a detective one. ## The governance attached to it An exception with no owner and no end state becomes permanent. At minimum record: who owns it (a named team), why it exists in one sentence, what must become true for it to be removed ("vendor publishes signed releases"), and a dated review. The review date is not a promise it will be gone — it is a forcing function to re-ask whether the reason still holds. And raise it commercially. Signed releases with verifiable provenance are now a normal procurement ask, and a vendor selling into regulated buyers has usually heard it before. The exception closes when the vendor signs, and nothing you do inside your own cluster achieves that; only the contract does. ## What a weak answer sounds like The weak answer is "we allowlist the vendor and move on" — it treats the exception as paperwork. The next-weakest is refusing outright: "no unsigned images, ever", which sounds rigorous and reliably ends with someone disabling enforcement in that namespace entirely, producing a wider hole with no record. The strong answer accepts that the exception must exist, makes it as small as the mechanism allows, prices the residual risk against the asset the workload can reach, and dates it.