Cloud Native 9 min read

Understanding Kubernetes Validating Admission Policies with Practical Examples

This article explains how Kubernetes Admission Controllers work, introduces the new Validating Admission Policies feature that uses CEL for native policy enforcement, and provides a step‑by‑step demonstration with YAML and kubectl commands showing how to limit deployment replicas in a namespace.

Cloud Native Technology Community
Cloud Native Technology Community
Cloud Native Technology Community
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 a request reaches the API server, it authenticates, authorizes, and then passes the request through Admission Controllers before persisting the object.

Admission Controllers are pieces of code that intercept API requests after authentication and authorization but before the object is stored. There are two main types: Mutating Admission Controllers, which can modify the incoming object, and Validating Admission Controllers, which can only reject requests that do not meet defined criteria.

Typical workflow: a user submits a YAML manifest (e.g., a Deployment). The API server checks permissions, forwards the request to Mutating Admission Controllers for possible modifications, then to Validating Admission Controllers for policy checks. If all checks pass, the object is stored in etcd.

Third‑party policy engines such as Kyverno , OPA Gatekeeper , and Datree implement their own Mutating and Validating Admission Webhooks to enforce policies. Kyverno runs as a dynamic admission controller inside the cluster, while Gatekeeper uses Rego policies, which can be harder to write for newcomers.

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

Below is a practical demonstration using a Kubernetes 1.27 cluster and the v1alpha1 API version. First, a namespace with the label environment: demo is created:

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

Next, a ValidatingAdmissionPolicy named demo-policy is defined to restrict the number of replicas for Deployments in that namespace to five or fewer:

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"

A corresponding ValidatingAdmissionPolicyBinding ties 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

Applying these resources with kubectl apply -f activates the policy. A test Deployment with six replicas is then attempted:

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

When applying this manifest ( kubectl apply -f deployment.yaml -n demo ), the API server rejects the request with 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

Reducing replicas to five allows the Deployment to be created successfully, confirming that the native policy works as intended.

This demonstration shows that Validating Admission Policies provide a simple, flexible, and native way to enforce cluster‑wide policies without external tools, while still allowing more complex rules via CEL expressions. As the feature matures to GA, it is expected to become a standard approach for policy management in Kubernetes.

References:

Emin Alemdar – LinkedIn profile

Original Medium article

Kyverno website

OPA Gatekeeper documentation

Datree website

Open Policy Agent project

Kubernetes documentation on Validating Admission Policies

Common Expression Language (CEL) specification

cloud-nativeKubernetesPolicy ManagementCELadmission-controllervalidating-admission-policy
Cloud Native Technology Community
Written by

Cloud Native Technology Community

The Cloud Native Technology Community, part of the CNBPA Cloud Native Technology Practice Alliance, focuses on evangelizing cutting‑edge cloud‑native technologies and practical implementations. It shares in‑depth content, case studies, and event/meetup information on containers, Kubernetes, DevOps, Service Mesh, and other cloud‑native tech, along with updates from the CNBPA alliance.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.