In a Kubernetes ValidatingAdmissionPolicy, what data can a CEL validation expression see?

## What a ValidatingAdmissionPolicy is, in one paragraph A `ValidatingAdmissionPolicy` is a Kubernetes API object that carries admission rules written as CEL (Common Expression Language) expressions. The API server evaluates them itself, in-process, on the write path, without calling out to anything. A companion `ValidatingAdmissionPolicyBinding` says which requests the policy applies to and supplies its parameters. Because the evaluation happens inline in every matching create, update or delete, the language is deliberately constrained: CEL expressions are total, side-effect-free, and bounded in cost. Understanding *what the expression is allowed to look at* is the first thing to learn, because it is also the thing that decides whether your requirement can live here at all. ## The variables you get - **`object`** — the resource as submitted. On a DELETE there is no incoming object, so `object` is null and the check has to read `oldObject` instead. - **`oldObject`** — the resource as it existed before this request. Null on CREATE. This is what makes "you may not change field X once set" expressible: compare `object` and `oldObject`. - **`request`** — the admission request attributes: the operation, the resource and subresource, the name and namespace, the requesting user's username and groups, and the `dryRun` flag. This is how a rule exempts a specific controller's service account, or declines to act on a dry run. - **`namespaceObject`** — the full Namespace object for the namespace the request targets. This is the single piece of surrounding cluster state you are handed, and it is handed to you: the API server has it already, so exposing it costs nothing. It is not a general lookup — you get *that* namespace, not any other object. - **`params`** — the parameter resource selected by the binding, present only if the policy declares a `paramKind`. This is the supported way to get data that is not in the request into the decision. - **`variables`** — named sub-expressions the policy defines, referenced as `variables.someName`, evaluated lazily and reused across validations. - **`authorizer`** — lets an expression ask the API server's authorizer a yes/no question, for example whether the requesting user could perform some verb on some resource. Note the shape of that: it is an *authorization decision*, not a data read. You can ask "may they?"; you cannot ask "what is?". On top of these, CEL supplies its standard macros — `has()` for field presence, `all()`, `exists()`, `map()`, `filter()` over lists — and Kubernetes adds a handful of extension libraries for things like URL parsing, regular-expression matching and resource-quantity comparison. ## What is deliberately absent There is no HTTP client. There is no API client. There is no way to list the other Pods in the namespace, look up the ConfigMap the workload references, read an image's metadata from a registry, consult a service catalogue, or remember what the same expression decided an hour ago. The expression is a pure function of the input it is given. This is not an oversight. The code runs on the API server's own write path for every matching request; a network call there would put an outside dependency in front of every write, make evaluation non-deterministic, and make request latency somebody else's problem to control. ## What this means in practice Take a concrete requirement: workloads may only be scheduled onto an approved set of node classes, expressed as a `nodeSelector` key and a set of matching tolerations. Every fact that rule needs is in the submitted object — the selector map and the toleration list are right there in the Pod template. The only thing that is not in the request is the *allowed set*, and that is exactly what `params` exists for. So the rule fits. Now change one word: workloads may only use node classes that the platform inventory currently marks as available. That fact lives in a service, and no variable in the list above will ever return it. The rule does not fit — not because CEL is a weak language, but because the venue gives it no way to reach the fact. The correct move at that point is to change where the check runs, or to change the shape of the requirement so the fact is delivered into `params` by something else. ## The common mistakes Candidates routinely assume admission can "see the cluster". It cannot. They assume `namespaceObject` implies a general read capability. It does not. They assume `object` is always populated. On DELETE it is null. And they assume `authorizer` is an escape hatch for fetching data. It answers permission questions only.