How should architects use ValidatingAdmissionPolicy with CEL instead of admission webhooks, and what failure modes still require webhooks?

Think of a building lobby with two security checks. One guard can read a badge and a printed rule list immediately, while another guard must call a remote office for approval. ValidatingAdmissionPolicy is the fast local rule list; a validating webhook is the remote phone call. Both can be useful, but the second one can delay every person entering the building if the phone line is slow.

In Kubernetes, admission control is the checkpoint between an API request and persisted cluster state. ValidatingAdmissionPolicy gives cluster administrators a native way to reject invalid resources with Common Expression Language, or CEL, which is a safe expression language designed for policy checks. Instead of operating a separate webhook service, TLS certificates, network path, scaling rules, and timeout behavior, the API server evaluates the expression directly.

The flow is precise. A ValidatingAdmissionPolicy defines match constraints and validation expressions. A ValidatingAdmissionPolicyBinding connects that policy to the resources and namespaces where it applies and specifies actions such as Deny. Optional parameter resources can make one abstract policy reusable across teams. When a matching CREATE or UPDATE request reaches admission, Kubernetes evaluates the CEL expression against the incoming object. If the expression returns false, the configured failure behavior decides whether the request is rejected.

In production, this is ideal for rules like requiring labels, limiting replica counts, blocking privileged settings, or enforcing image registry patterns. Operators should monitor admission rejection rates, API server latency, policy rollout changes, and namespace selectors. Policies should be rolled out gradually because one bad rule can block deployments across many services. Use audit or warning-style validation before deny when the blast radius is unknown.

The gotcha is treating CEL as a total replacement for admission webhooks. CEL should not call external systems and cannot mutate resources. If policy needs live inventory from a CMDB, vulnerability scanner, signing service, or custom approval database, a webhook or controller may still be required. Architects should prefer CEL for fast predictable (deterministic) checks and reserve webhooks for cases where the policy genuinely needs external state.