Can a ValidatingAdmissionPolicy enforce an allowlist that only an external inventory service knows?

## Why the answer is no, and why that is not the interesting part The input surface of an admission CEL expression is fixed: the incoming object, the previous object, the request attributes, the request's namespace object, and the parameter resource the binding selected. There is no HTTP client, no API client, no cache. This is deliberate — the expression runs inline on the API server's write path, so a lookup there would make every matching write depend on a third party's availability. So a requirement phrased as "only node classes the platform inventory currently marks as available" cannot be evaluated in-tree. The interview does not stop there. What an interviewer is testing is whether you can convert an unmeetable requirement into a met one by changing where or how it is enforced. ## Option one: mirror the fact into params Run a controller that reads the inventory on a schedule and writes the current allowed set into the parameter resource the policy is bound to. The expression stays trivial — a membership test against `params` — and the rule enforces continuously with no dependency in the request path. What you have accepted is a staleness window. Between the inventory changing and the mirror catching up, admission is enforcing yesterday's answer. Whether that matters depends on the direction of the change: a class being *added* late is a minor annoyance, a class being *withdrawn* late means you kept admitting workloads onto something that was retired. The subtlety candidates miss is that **the rule cannot detect its own staleness**. The expression has no way to reach outside its input to check whether the mirror is current, so freshness has to be enforced by the controller, not by the rule. The pattern that works is: the controller narrows or clears the parameter resource when it cannot confirm the inventory, and the binding sets `parameterNotFoundAction: Deny`, so a mirror that stops working degrades into refusal rather than into silent permissiveness. That is a decision you make deliberately — a fail-closed mirror can turn an inventory outage into a cluster-wide deployment freeze, and someone has to agree that is the trade you want. ## Option two: split the rule Most requirements that look like they need a lookup are actually two requirements welded together. Take them apart: - **Self-contained half** — the workload declares a node class at all; the value matches the naming convention; the tolerations are consistent with the selector; nothing carries a blanket toleration. All of this is in the submitted object, all of it is cheap, and all of it belongs in the in-tree policy as a permanent backstop that cannot be bypassed by any path into the cluster. - **Lookup half** — is *this* class currently approved for *this* workload. Enforce that where the lookup is natural and cheap: in the pipeline that renders the manifest, or in the reconciler that syncs it, where a network call costs nothing and the failure is a red build rather than a rejected write. The result is a coarse, always-on guardrail in the cluster and a precise check earlier. That is usually a better control than either half alone, because the in-cluster half survives someone bypassing the pipeline and the earlier half gives the developer a fast, specific failure. ## Option three: relocate the whole rule Move it to an external policy engine — a webhook-based engine such as Gatekeeper, Kyverno or Kubewarden — that can reach the fact, or supply it from data the engine replicates itself. Be honest about what changes: you now operate a component in the admission path, and the requirement's availability is coupled to it. That is a legitimate choice when the lookup is genuinely central to the control; it is a poor one when you have reached for it to avoid the mirroring work. ## How to answer this in an interview Lead with the constraint and the reason for it, then present the three moves and pick one for the case at hand, naming the trade you are accepting. If the fact changes rarely and matters a lot, mirror it and fail closed. If the fact is really a business decision about what a team may request, push it left into the pipeline and keep a structural backstop in-cluster. If the fact must be consulted at the moment of the write and nothing else will do, run an engine and own the dependency. The wrong answer is any of the three offered as *the* answer, and the very wrong answer is claiming CEL can be made to fetch it.