Understanding Kubernetes Validating Admission Policies with Practical Examples

Kubernetes API server is a core component of the control plane that exposes the Kubernetes API and acts as the front‑end for all cluster interactions. When users or processes send requests, the API server validates and configures objects such as Deployments or Namespaces, often with the help of Admission Controllers.

According to the official documentation, an Admission Controller is a piece of code that intercepts requests to the API server after authentication and authorization but before the object is persisted. There are two kinds: Mutating, which can modify the incoming object, and Validating, which only checks the request and can reject it.

In practice, a user submits a YAML file containing object definitions (e.g., a Pod or Deployment) to the API server. The request first passes authentication, then is sent to Mutating Admission Controllers that may alter the object, followed by Validating Admission Controllers that ensure the final definition conforms to policy before it is stored in etcd.

Third‑party policy engines such as Kyverno , OPA Gatekeeper and Datree implement Mutating and Validating Admission Webhooks to enforce policies. For example, Kyverno runs as a dynamic admission controller inside the cluster, while Gatekeeper uses the Rego language of the Open Policy Agent, which can be steep for newcomers.

Starting with Kubernetes 1.26 (Alpha) and 1.28 (Beta), the platform introduces native Validating Admission Policies . These policies use the Common Expression Language (CEL) to define declarative, parameterized rules directly in the API, eliminating the need for external webhooks.

Although native policies may reduce reliance on external tools, the author believes projects like OPA Gatekeeper and Kyverno will adapt rather than disappear, as many users prefer a single, built‑in solution for policy enforcement.

Let’s see a practical example of Kubernetes Validating Admission Policies!

Before the demo, note that the feature is disabled by default; you must enable the appropriate feature gate and the correct API version (admissionregistration.k8s.io/v1alpha1 or v1beta1) for your Kubernetes version. The demo uses a 1.27 cluster with the v1alpha1 API.

Two resources are required: a ValidatingAdmissionPolicy that defines the rule, and a ValidatingAdmissionPolicyBinding that attaches the policy to a target such as a namespace.

First, create a simple namespace:

apiVersion: v1
kind: Namespace
metadata:
  labels:
    environment: demo
  name: demo

Next, define the policy that limits the number of replicas for Deployments in namespaces labeled environment=demo :

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicy
metadata:
  name: "demo-policy"
spec:
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
    - expression: "object.spec.replicas <= 5"
      message: "You can not have more than 5 replicas in the demo namespace for deployments"

Then create a binding that applies the policy to the demo namespace:

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "demo-binding"
spec:
  policyName: "demo-policy"
  validationActions: [Deny]
  matchResources:
    namespaceSelector:
      matchLabels:
        environment: demo

Apply the namespace, policy, and binding with kubectl apply . Now test the policy by attempting to create a Deployment with six replicas:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
  labels:
    app: nginx
spec:
  replicas: 6
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx

Apply the deployment:

kubectl apply -f deployment.yaml -n demo

The creation is rejected as expected, and the API returns the following error:

The deployments "demo-app" is invalid: : ValidatingAdmissionPolicy 'demo-policy' with binding 'demo-binding' denied request:
You can not create more than 5 replicas in the demo namespace for deployments

If the replica count is changed to 5, the deployment succeeds, demonstrating that the native policy works correctly.

In summary, Validating Admission Policies make it straightforward to write, enforce, and manage policies inside Kubernetes without external webhooks, leveraging CEL for expressive, parameterized rules. The feature is currently in beta (Kubernetes 1.28) and is expected to become a standard part of cluster policy management.

References

Emin Alemdar: https://www.linkedin.com/in/emin-alemdar/

Medium article: https://eminalemdar.medium.com/policy-management-in-kubernetes-is-changing-9d4808f548a0

Kyverno: https://kyverno.io/

OPA Gatekeeper: https://open-policy-agent.github.io/gatekeeper/website/

Datree: https://www.datree.io/

Open Policy Agent: https://www.openpolicyagent.org/

Validating Admission Policies documentation: https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/

Common Expression Language (CEL): https://github.com/google/cel-spec