What is Kubernetes Validating Admission Policy?

In Kubernetes 1.26, a new type of policy Validating Admission Policy was introduced. Validating admission policies offer a declarative, in-process alternative to validation using dynamic  admission webhooks. Previously, dynamic admission webhooks were required for custom validation of Kubernetes API requests. With Validating Admission Policy, validation rules can be declared using Common Expression Language (CEL). In this blog post, we will dive deeper into Validating Admission Policies by understanding CEL and discussing how it can be used to validate resources. 

Common Expression Language

Common Expression Language (CEL) is an open-source non-Turing complete language that implements common semantics for expression evaluation. CEL was first introduced to Kubernetes for the Validation rules for CustomResourceDefinitions and then it was used by Kubernetes Validating Admission Policies in version 1.26. The CEL language has a straightforward syntax that is similar to the expressions in C, C++, Java, JavaScript and Go.

With CEL expressions you can do the following:

• Define policies that take into account multiple fields and values in a resource, and make decisions based on the outcome of those conditions.
• Use logical operators, comparison operators, and custom functions to create policies that are easier to read and understand.
• Define your own custom functions and operators, which can be used to customize the behavior of your policies.

Here is an example of a CEL expression:

self.health.startsWith('ok')

The above expression validates a ‘health’ string field has the prefix ‘ok’

Validating Admission Policy

A Validating Admission Policy enables policy authors to define policies that can be parameterized and scoped to resources as needed by cluster administrators. 

To create a policy, two resources are needed:

• A ValidatingAdmissionPolicy resource that defines the logic of the policy using CEL
• A ValidatingAdmissionPolicyBinding resource that connects the policy to a scope (e.g. Pod or Secret)

Additionally, a Parameter resource can be specified to provide additional information to a ValidatingAdmissionPolicy. If a ValidatingAdmissionPolicy does not need to be configured via parameters, the spec.paramKind in ValidatingAdmissionPolicy should not be specified.

Here is an example of a Validating Admission Policy. This policy limits the number of replicas in a Deployment to three or less.

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingAdmissionPolicy
metadata:
  name: "limit-replicas-policy"
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
    - expression: "object.spec.replicas <= 3"
      message: "Deployment should not use more than 3 replicas"

This policy can be applied to specific resources by creating the Validating Admission Policy Binding. In the example below, the policy will be applied to deployments in namespaces that have the label “environment=test”

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

Once, this policy and its binding are added, if a user tries to create a deployment with replicas greater than three in any namespace with environment label set to “test”, the request will be denied with the message “Deployment should not use more than 3 replicas”

Key Considerations

• VAP can be very effective in performing simple validation checks at admission without requiring additional admission controllers.
• CEL is easy to learn and flexible for simple policies but writing more complex policies could be challenging.
• More advanced validation checks such as image signature verification, or checks which require API lookups, are not possible. 
• Since ValidatingAdmissionPolicy focuses on validation checks, a different solution is required for policies that mutate and generate resources.
• Managing multiple policy resources (ValidatingAdmissionPolicy, ValidatingAdmissionPolicyBindings) introduces some overhead and requires automation. 
• Currently ValidatingAdmissionPolicy can make “allow” or “deny” decisions but in case the policy requirements change the new policy cannot be applied to existing cluster resources.
• Policy exception management is not very straightforward, as it requires managing bindings or creating multiple policies
• Policy reports for ValidatingAdmissionPolicy are not available.
• ValidatingAdmissionPolicy cannot be applied in a CI/CD pipeline via a CLI.

Summary

As you can see it is very easy to write validation checks using ValidatingAdmissionPolicy. CEL is fairly easy to learn and very flexible. Using ValidatingAdmissionPolicy to validate configuration can reduce the dependency on external admission webhooks such as Kyverno and OPA/Gatekeeper. But there are also several scenarios that ValidatingAdmissionPolicy does not currently address and require external admission controllers. We will discuss these in an upcoming series of blog posts, and showcase how CNCF policy engines like Kyverno are adding support for ValidatingAdmissionPolicy.