DevOps Dictionary

Kubernetes ValidatingAdmissionPolicy is a built-in Kubernetes admission control resource that validates API requests using Common Expression Language (CEL) rules before Kubernetes stores the object. In practical terms, it lets you enforce rules such as required labels, allowed image registries, replica limits, or security settings without running a custom validating webhook server.

What it does

A ValidatingAdmissionPolicy checks create, update, delete, or connect requests sent to the Kubernetes API server. If a request violates the policy, Kubernetes can deny it, warn the user, or record it in audit logs, depending on how the policy binding is configured.

Teams use it to apply guardrails at the API layer, so the same rules apply whether resources are created by kubectl, Helm, Argo CD, Terraform, Crossplane, or a CI/CD pipeline.

How it works

ValidatingAdmissionPolicy uses CEL expressions to inspect the requested object and related request data. A policy defines the validation logic, while a ValidatingAdmissionPolicyBinding decides where and how that policy applies.

• ValidatingAdmissionPolicy: Defines the CEL rules, target resource types, failure behavior, and optional parameters.
• ValidatingAdmissionPolicyBinding: Connects the policy to specific namespaces, objects, or resource scopes.
• CEL expressions: Evaluate fields such as object, oldObject, request, params, and namespaceObject.
• Validation actions: Can include Deny, Warn, and Audit.

For example, a CEL rule can reject a Deployment if it has more than 10 replicas, or reject a Pod if one of its containers uses an image from an unapproved registry.

Common use cases

• Require labels such as team, environment, or cost-center on workloads.
• Limit resource settings, such as maximum replicas or required CPU and memory requests.
• Block risky configuration, such as privileged containers or host namespace access.
• Restrict container images to approved registries.
• Apply policy checks to resources created by GitOps, CI/CD, or infrastructure as code tools.
• Validate custom resources, including resources managed by platforms such as Crossplane.

Simple example

A platform team may want every Deployment in production to include an owner label. A ValidatingAdmissionPolicy can check that the label exists, and a binding can apply the rule only to namespaces with environment=production. If a developer deploys a workload without that label, the API server rejects the request before the Deployment is saved.

This is useful when many teams deploy through different paths. The same rule still applies whether a team uses Helm, GitOps, or a Terraform workflow such as deploying Kubernetes resources using Terraform.

How it differs from validating webhooks

ValidatingAdmissionPolicy is often compared with ValidatingAdmissionWebhook because both validate Kubernetes API requests. The main difference is operational complexity.

• ValidatingAdmissionPolicy: Runs inside the Kubernetes API server using declarative CEL rules. It does not require you to deploy, scale, secure, or monitor a webhook service.
• ValidatingAdmissionWebhook: Calls an external HTTP service. It can support more complex logic, external lookups, and custom code, but it adds runtime dependencies and failure modes.

ValidatingAdmissionPolicy is a good fit for field-based checks that can be expressed in CEL. A webhook may still be better when the rule needs external data, complex business logic, or integration with another system.

How it differs from mutation and policy engines

• MutatingAdmissionWebhook: Changes an object before storage. ValidatingAdmissionPolicy only validates; it does not modify objects.
• Pod Security Admission: Enforces predefined pod security levels. ValidatingAdmissionPolicy can enforce custom rules across many Kubernetes resource types.
• OPA Gatekeeper and Kyverno: Provide broader policy frameworks with their own features and controllers. ValidatingAdmissionPolicy is built into Kubernetes and uses CEL.

Benefits

• Lower operational overhead: No separate webhook server is required for common validation rules.
• Consistent enforcement: Rules run at the Kubernetes API layer for all clients and deployment tools.
• Declarative configuration: Policies can be stored in Git and applied like other Kubernetes resources.
• Good fit for platform guardrails: Platform teams can set clear boundaries without controlling every deployment pipeline.

Tradeoffs and limitations

• No mutation: It can reject or warn, but it cannot add missing fields or change values.
• CEL learning curve: Engineers need to understand CEL syntax and Kubernetes admission variables.
• Limited external context: It does not call external APIs the way a custom webhook can.
• Version awareness matters: ValidatingAdmissionPolicy availability and behavior depend on your Kubernetes version, so include it in your planning when reviewing Kubernetes upgrade practices.

Where it fits in platform engineering

ValidatingAdmissionPolicy works well as part of a layered control model. For example, a platform team can use it to validate application workloads, infrastructure custom resources, and namespace-level standards. If your team manages cloud infrastructure through Kubernetes APIs, such as with AWS resources using Crossplane on Kubernetes, admission policies can help enforce required fields before those resources reach controllers.

The best use cases are clear, deterministic rules. Start with a small set of high-value checks, test them with Warn or Audit actions, then move to Deny once teams understand the impact.