Your admission engine may be injecting an undeclared sidecar into every Pod: how do you confirm it and contain it?

## Reading the symptom An extra container that nobody declared has three tells that separate an enforcement-plane compromise from an ordinary mistake: 1. **It crosses ownership boundaries.** The same container is in Pods belonging to teams with different repositories, different pipelines and different reviewers. No single team's change explains that. 2. **It appears at recreation, not at merge.** Workloads gained it when Pods were rescheduled, drained or rolled — not when anything landed in a repository. Admission acts on API requests, so its effect follows Pod churn. 3. **It is in the cluster and nowhere else.** Diff live objects against the source that produced them — the desired state your delivery tooling reconciles, or the recorded last-applied configuration. The injected container is present only in the stored object. ## Confirming it was admission The stored object itself will not tell you. There is no field on a Pod naming the webhook that patched it; once the patch is applied, the object looks exactly like a legitimately declared one. The place to look is the API server's audit trail: at an audit level that records both the request and the response object, you can see the object as the client submitted it and the object as it was persisted. If the container is absent from the first and present in the second, the change happened inside the admission chain, not in a client. Cross-check that the affected objects are exactly the set your mutating registration matches — that correspondence is strong evidence. ## Containing Containment is removing or narrowing the mutating webhook registration, which stops the API server forwarding those requests to the engine at all. Then be precise about what is and is not fixed: - **Running workloads do not revert.** The patch was applied at admission, so existing Pods carry the sidecar until they are recreated. Rolling them is a deliberate, sequenced step, not a side effect of removing the registration. - **Exfiltration is already done.** Every object the match selected during the window was sent to the engine in full. If the match included Secrets or ConfigMaps, treat the credentials in them as disclosed and rotate them; scoping that rotation is usually the largest part of the incident. - **The engine's own footprint is in scope.** It is a workload with credentials, network egress and, in most designs, a place it ships records of what it decided. All of that is part of the investigation. - **The injected sidecar is evidence.** Its image, the registry it came from, its mounts and its outbound connections tell you what the injection was for. ## The trap: verifying with the thing you are investigating The instinct is to ask the policy plane whether the cluster is clean now. Do not. The validating rules that would flag an unexpected container almost always come from the same engine, and they run after mutation, on the already-patched object. A compromised plane will happily report compliance. Verification has to come from outside it — a diff of live state against source, run by your delivery tooling or a separate reader, is the honest check. ## Afterwards Two structural lessons usually come out of this class of incident. The first is that the match was wider than any rule needed: the engine was receiving — and could inject into — far more than the guardrails required, so narrowing the match shrinks both channels at once. The second is that nothing outside the enforcement plane was comparing live objects to their declared source, which is why a cluster-wide change went unnoticed. That detection has to be owned by something the enforcement plane does not control, because the enforcement plane is the component nobody is watching: it is the thing that watches.