Skip to main content
Kubernetes operators focus on reconciliation: creating child objects, reporting status, emitting events, and cleaning up external state when a custom resource is deleted. Those reconciliation behaviors occur after a WebApp custom resource already exists in the API server—typically after you run:
Validating admission moves part of that safety boundary earlier, so Kubernetes can reject an invalid WebApp before it ever reaches the controller. The Kubernetes feature used here is ValidatingAdmissionPolicy: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionpolicy A validating admission policy executes during admission—the API server step that inspects create and update requests before persisting them. Policies are written with CEL (Common Expression Language) to evaluate expressions against the object in the incoming request. For a custom resource like WebApp, the API server can evaluate fields such as spec.image and spec.replicas before the controller ever sees the object. If a CEL expression evaluates to true, the API server may allow the request to continue. If it evaluates to false and the associated binding enforces deny, the API server rejects the request and returns the policy’s validation message.
The image illustrates a decision process titled "The Verdict: Allow or Deny," where "CEL evaluates" requests. If true, the request continues; if false, the API server rejects the request.
A policy defines the validation logic, matching constraints, and the message returned on failure. A separate binding activates the policy and chooses the enforcement action and scope (namespaces, users, operations). This separation lets you stage policies in the cluster without affecting requests until a binding is applied. For the WebApp API in this demo, we enforce two object-level checks using CEL:
  • Images must not use the mutable :latest tag, because moving tags reduce repeatability and make rollouts unpredictable.
  • Explicit replica counts must be within a supported range so extreme values are rejected before the controller begins reconciling.
Example CEL expressions for these checks:
Summary of the rules enforced This demo includes a ValidatingAdmissionPolicy and a matching ValidatingAdmissionPolicyBinding for these rules. You’ll see two test cases: applying an invalid WebApp manifest (to observe rejection) and applying a valid manifest (to observe acceptance). The provided policy manifest uses placeholders so you can insert the CEL expressions and validate the API server behavior. Example fragment in the policy manifest where you fill in CEL expressions:
Policies and bindings are distinct: policies hold logic and messages, while bindings control scope and enforcement. This lets you stage validation rules in the cluster before applying them to requests.
References and further reading

Watch Video