Skip to main content
In this lesson we’ll add admission-time validation for a custom WebApp resource by authoring a ValidatingAdmissionPolicy that evaluates CEL expressions. The WebApp controller itself does not change — instead the policy executes inside the API server and decides whether CREATE/UPDATE requests are allowed before objects are persisted. Create the ValidatingAdmissionPolicy that targets the WebApp resource. Note the API version admissionregistration.k8s.io/v1, which is the Kubernetes API group that defines validating admission policies.
Using failurePolicy: Fail ensures that if the policy cannot be evaluated, or a validation fails, the API server will block the matching request rather than allowing it to proceed silently.
Policy fields — concise explanation:
  • matchConstraints.resourceRules — scopes the policy so it only evaluates requests for the webapps resource in the webapp.kodekloud.com/v1 API group during CREATE and UPDATE operations.
  • validations — an array of CEL expressions that must evaluate to true for the request to be allowed. The incoming object is available in CEL as object.
    • First validation:
      • Expression: !object.spec.image.endsWith(':latest')
        This denies requests where spec.image ends with :latest, enforcing pinned image tags.
    • Second validation:
      • Expression: !has(object.spec.replicas) || (object.spec.replicas >= 1 && object.spec.replicas <= 10)
        Because replicas is optional in the CRD, this expression allows missing replicas but requires present values to be between 1 and 10.
      • messageExpression constructs a rejection message that embeds the actual invalid value for clearer errors.
Summary of validations: Next, create a ValidatingAdmissionPolicyBinding to activate the policy. The binding attaches the policy to evaluation and sets the validation action to Deny.
Apply the policy and its binding so the API server can begin evaluating matching WebApp CREATE and UPDATE requests:
After the binding is observed by the admission plugin, the API server will evaluate matching WebApp CREATE and UPDATE requests using the policy before persisting them to etcd or sending them to any controller. Test the policy with sample WebApp manifests:
  1. Apply a WebApp that uses an unpinned image (:latest):
The API server denies the request with the image rule message — proof the CEL policy ran at admission-time.
  1. Apply a WebApp with an acceptable image but invalid replicas (50):
The denial message includes the rejected replica count, thanks to the configured messageExpression.
  1. Apply a WebApp that satisfies both rules (pinned image and valid replicas):
Same CRD and controller — but the API server now prevents invalid desired state from entering the system, reducing wasted controller processing and improving feedback to API clients. Inspecting policy status:
When to use validating admission policies with CEL:
  • Good for centralized, fast checks on object-local properties: image tag pinning, numeric bounds, required labels/annotations, simple string patterns.
  • Not intended for complex business logic that requires cross-resource checks or external calls — those belong in controllers or external admission webhooks.
References:

Watch Video

Practice Lab