A Kubernetes admission rule exempts one username, yet still blocks that user's Deployment — why?

## Identity does not survive the controller hop The admission request carries who made *that* request. When you apply a Deployment, that is you. When the ReplicaSet controller subsequently creates a Pod, the requester on that request is `system:serviceaccount:kube-system:replicaset-controller`, with the groups any service account carries — `system:serviceaccounts`, `system:serviceaccounts:kube-system` and `system:authenticated`. The person is gone. There is no field anywhere in the Pod's admission payload that names them, and the payload carries no other object you could consult to find out. So any rule clause of the form "skip this check when the requester is X" only works at the hop where X is the requester. Applied to a Pod-level rule, an exemption for a human never fires. ## Why exempting the controller is the wrong repair The first instinct — "fine, exempt the ReplicaSet controller service account" — collapses the rule. Every Pod behind every Deployment in the cluster is created by that one account. Exempting it does not exempt the one team that asked; it exempts effectively the whole estate, and it does so invisibly, because the rule still exists, still evaluates, and still reports green. The same applies to broad group matches: excluding `system:serviceaccounts:kube-system` takes out the controllers that create almost all workload Pods. The general principle is worth stating plainly in an interview: **on a Pod-level rule, requester identity is a poor axis to make decisions on, because it is almost always a controller.** Requester-based logic belongs on rules that match the object the human submits. ## What does travel What reaches the Pod is what the controller copies into it — the contents of the workload's **pod template**. Labels and annotations placed under a Deployment's `spec.template.metadata` land on every Pod it produces; labels and annotations on the Deployment's own `metadata` do not. That distinction is the whole trick, and it is the thing candidates get backwards. Practical options, roughly in order of preference: - **Scope by namespace.** The Pod's namespace is on the Pod. If the exemption is really "this team's environment", a namespace scope expresses it directly, is visible in the rule, and is governed by whoever controls namespace creation. - **Scope by a pod-template label or annotation.** Workable, and it travels — but note who can set it. Anyone who can edit the Deployment can add the exemption marker to its pod template, so this is a request, not a control, unless a second rule governs who may set that marker. - **Put the exemption on the parent rule instead.** If you also run a rule against Deployments for feedback, an identity-based exemption is meaningful there, because the human really is the requester. ## The evidence problem There is an audit consequence too. If your record of "who was allowed to do this" comes from the Pod-level evaluation, every entry attributes the action to a controller. Reconstructing the human requires correlating back to the workload write in the API server's audit trail. Design the exemption so the record names a namespace, a workload, or an approval reference — something with an owner — rather than relying on an identity that was never in the request. ## How to answer this out loud Name the mechanism (identity is per-request and the Pod's requester is a controller), name the trap (exempting that controller exempts nearly everything), then give the axis that actually travels (namespace, or pod-template metadata rather than the workload's own metadata), and close on who is allowed to set it.