The Engine's Blast Radius

## Two kinds of rule, two very different kinds of power An admission rule sits between a request to the Kubernetes API server and the object being persisted. A **validating** rule can only return a verdict: allow, or deny with a message. A **mutating** rule returns a patch, and the API server applies it — the object that ends up in etcd, and therefore the workload that actually runs, is the patched one. Mutating admission runs first; validating admission then sees the already-patched object. ## Why teams choose mutation anyway Take a real guardrail: all outbound traffic from workloads must leave through an egress proxy. Written as a validating rule, it rejects any Pod without the proxy sidecar — correct, but it hands work to every team in the estate, and the rollout is a migration with hundreds of pull requests. Written as a mutating rule, the platform injects the proxy sidecar and the matching `NO_PROXY` environment into every Pod at admission. Nobody edits a manifest, adoption is instant, and compliance is a property of the platform rather than of each team's diligence. This is a genuinely good reason to mutate, and it is why mutating rules are common. ## The same rule, inverted Now read that capability as an attacker would. The rule is a mechanism that inserts an attacker-chosen container into every Pod that matches, across every namespace, with whatever image, mounts and environment the patch specifies. Compromise the engine — or the content of the rules it serves — and you do not need access to a single team's repository, a single ServiceAccount, or a single node. You get workload execution wherever the match reaches. Three properties make this worse than the equivalent compromise of a normal deployment: - **It is silent.** The injected container is not in the submitted manifest and not in the source repository. It *is* in the stored object, but the stored object has no field saying "a webhook added this". Someone comparing live state to source will see the difference; nobody comparing a Pod to its own spec will. - **The watcher is the thing that changed it.** Validating rules that might have flagged an unexpected container usually come from the same engine, and they run after the mutation. A plane cannot be trusted to police itself. - **It spreads on ordinary operations.** Admission acts on requests, so already-running Pods are untouched until they are recreated. A node drain, a rollout or a scale event is what carries the injection outward — which also means it can arrive hours or days after the compromise. ## Validating rules are not harmless A validating rule cannot change what runs, but it still receives the full body of every object its match rules select, and a rule that denies can deny broadly. So the distinction is specific: mutating rules add **write into every matched workload**; both kinds already carry **read of every matched object**. ## Shrinking the blast radius The questions to ask about any mutation you operate are: does this rule need to mutate at all, or would rejecting with a clear message do? Does it need an external engine, or can it be an expression the API server evaluates itself — a `ValidatingAdmissionPolicy` runs CEL in-process, cannot make network calls, and can only reject, never modify, so there is no remote endpoint to compromise. And how narrow is the match? The set of requests the API server sends to the engine is the set of objects the engine can read and, for a mutator, the set of workloads it can write into. Narrowing that match is least privilege for the engine, not throughput tuning. Finally, the mutation content itself — the injected image, its registry, its digest, the volumes it mounts — deserves the review you would give any privileged workload, because that is exactly what it is.