Your admission rule needs data from other cluster objects: should the engine get a standing cluster-wide read?

## Two channels, not one An in-cluster policy engine holds power along two independent paths: - **Push** — every object body the API server sends it because its match rules selected the request. This is unaffected by the engine's own permissions and is bounded only by the match. - **Pull** — whatever the engine's own API credentials let it fetch on its own initiative. Most reviews only look at the second, because that is the one that appears in a configuration file. The first is invisible unless someone reads the match rules as a privilege statement. ## Why the pull channel keeps growing An admission request carries the object under review, the previous version on an update, and who asked — and nothing else. No other object, no cluster state, no history. So the moment a rule needs context, it cannot be answered from the request. "Is this image on the organisation's approved list?" "Does this team already own this hostname?" "Has this namespace exhausted its allocation?" Every one of those pushes an author toward giving the engine a client and a read role, and because it is tedious to enumerate what each rule needs, the read granted is usually broad. The result is a single deployment that receives every matched object body *and* can read the rest of the cluster on demand. Compromise it and you have both. And it is the component least likely to be questioned, because it is the component that does the questioning. ## A decision framework **1. Can the data travel with the rules instead of being queried?** An approved-registry list, an ownership map, a set of exempted namespaces — these change slowly. Delivered as configuration the engine already holds, the rule needs no read at all. The cost is staleness: ask how long a wrong answer is tolerable. For most policy inputs, minutes or hours is fine. **2. If it must be live, how narrow can the read be?** Read-only, specific resource types, specific namespaces where possible, never write. A rule that needs one resource type does not justify a credential that reads everything. **3. Does the check belong at admission at all?** Admission is the wrong place for anything requiring a broad view of the cluster: it is synchronous, it is on the critical path of every matched request, and the request gives it no context by design. The same check running after the fact — reading state on its own schedule, reporting rather than blocking — can hold its own scoped credential and does not put a cluster-wide reader in the request path. You trade prevention for detection, which is sometimes the right trade and should be an explicit one. **4. What does the rule actually prevent?** This is the question that usually settles it. If the rule closes a path an attacker realistically takes, the credential may be worth it. If it enforces a convention, it is not worth turning the enforcement plane into a cross-namespace reader. ## The organisational layer Whoever operates this engine holds a cluster-wide read and, if it mutates, a cluster-wide injection primitive. That should place it in the same review category as any other highly privileged workload: named owners, a change process for what it enforces, a supply chain for its own image, and an upgrade path someone is accountable for. It also argues for splitting responsibilities — the component that detects drift should not be the component that can cause it. One framing to keep out of the discussion: that narrowing the match, or the read, is about performance. It is occasionally true and always beside the point. Both are the boundary of what a single compromised deployment can reach, and they should be argued and reviewed on those terms.