In a pull-based deploy every apply arrives as the reconciler - how do you enforce a rule that depends on who authored the change?

## The collapse In a pull-based pipeline every write to the cluster is made by one component: the reconciler. It authenticates as its own identity, and that identity is the same whether the manifest came from the payments team or from a summer intern, whether the commit was reviewed by four people or force-pushed. From inside the cluster, all changes look like the same actor doing the same thing over and over. This is not a gap to be patched; it is the direct consequence of centralising the credentials in one agent, which is the property that made pull-based delivery attractive in the first place. Nobody outside the cluster holds cluster credentials any more, and the price is that nobody outside the cluster is visible to it either. ## What that does to who-rules Call a rule a *what-rule* when it can be decided from the object alone, and a *who-rule* when it depends on the requester. Examples of each, using the rules this kind of gate typically carries: - What-rule: every namespace must come with a NetworkPolicy. Every workload must declare CPU and memory requests and limits. - Who-rule: only the platform team may raise a namespace memory limit above the standard ceiling. Only the networking team may create a namespace with a permissive policy. What-rules work perfectly at the cluster gate; the object carries everything the decision needs. Who-rules do not work at all, because the answer to *who* is always the reconciler. A who-rule expressed at the gate collapses into one of two useless states: it permits the reconciler and therefore permits everybody, or it denies the reconciler and therefore denies everybody. ## Where identity actually exists It exists in the repository, and only there. The forge knows who opened the change, who pushed the commits, which review approvals were given and by whom, and which team owns the path the change touches. Those facts are asserted by the forge, not by the change, which is exactly the property that makes them worth trusting. So the design is a split, and the split is the answer to the question: - **In the cluster:** the invariant. Decidable from the object, indifferent to who asked, enforced on every write including ones that bypass your repository entirely. - **In the repository:** the authority. Ownership on the directory that holds the limits, a required review from the group that owns the ceiling, a protected path that only certain reviewers can approve. Each control does what its position lets it prove, and neither pretends to do the other one job. ## The trap: identity smuggled into the object The tempting shortcut is to put the identity into the manifest so the gate can see it. An annotation naming the approving team. A label saying the exception was granted. A commit trailer copied into the object. Every one of these is written by the author, in the same commit, and arrives at the gate as ordinary object data. The gate cannot distinguish an annotation the platform team really added from one the author typed. It is a self-asserted claim, and treating it as an authorisation decision is the same error as trusting a client-supplied role header. If the annotation is worth anything at all, it is because a review on the path where it lives required a second principal to accept it - which means the enforcement was in the repository the whole time, and the annotation is only a record. The same reasoning covers the commit author field: it is metadata the committer sets, not an authenticated identity, unless something independent vouches for it. ## Options you can offer, with their real costs **One reconciler identity per team.** Give each team its own agent instance or its own credentials, scoped to its own namespaces. You regain coarse attribution - the gate can now tell payments from search - and you can scope rules per team. You do not regain per-human granularity, and you pay in N identities, N sets of credentials and per-team configuration that drifts. **Making the reconciler act as the author.** In principle a system can act on behalf of another identity. In practice you would need a trustworthy mapping from a commit to a cluster identity, and the only thing proposing that mapping is the commit itself; you would also be handing the agent the standing ability to act as anyone. That trade is almost never worth it, and being able to explain why is more valuable in an interview than proposing it. **Accepting the split.** Usually correct. Invariants at the gate, authority in the repository, and a clear statement to teams about which control is answering which question. ## What a weak answer looks like Writing the who-rule at the gate anyway and not noticing it can never fire differently for two teams; trusting an approver annotation; or asserting that the change author reaches the cluster. The moment you say the gate can see the human, the design built on top of it is wrong.