Explore Validating and Mutating Admission Policies [page]deterministic

This page lets you try out declarative _admission policies_, which allow you to use the Common Expression Language (CEL) to validate or mutate resources.

Kubernetes supports two kinds of admission policy:

• [ValidatingAdmissionPolicy](/docs/reference/access-authn-authz/validating-admission-policy/)
• [MutatingAdmissionPolicy](/docs/reference/access-authn-authz/mutating-admission-policy/)

This tutorial covers both kinds of admission policy.

##

To define admission policies, you must be a cluster administrator. Make sure you have administrator access to the cluster where you are learning.

For ValidatingAdmissionPolicy, you need: * A cluster running version 1.30 or later.

For MutatingAdmissionPolicy, you need: * A cluster running version 1.36 or later.

To check the version, run `kubectl version`. If you are running an older version of Kubernetes, check the documentation for that version.

## What are declarative admission policies?

Declarative admission policies offer a declarative, in-process alternative to admission webhooks.

By using the Common Expression Language (CEL) to declare policy rules, these policies are evaluated directly within the API server.

These policies are highly configurable, enabling policy authors to define logic that can be parameterized and scoped to resources as needed by cluster administrators.

### API types for admission policies

The two types of policy have different purposes.

ValidatingAdmissionPolicy is for _enforcing constraints_.

MutatingAdmissionPolicy is for _modifying resources during admission_.

### Policy elements

Each applied policy always has a _policy_ object (ValidatingAdmissionPolicy or MutatingAdmissionPolicy) and a separate _binding_ object (ValidatingAdmissionPolicyBinding or MutatingAdmissionPolicyBinding).

You can also use _parameters_, which are optional. To learn more, see [parameter resources](/docs/reference/access-authn-authz/validating-admission-policy/#parameter-resources) (ValidatingAdmissionPolicy) or [parameter resources](/docs/reference/access-authn-authz/mutating-admission-policy/#parameter-resources) (MutatingAdmissionPolicy).

Policy objects describes the abstract logic of a policy using Common Expression Language (CEL). For example, a ValidatingAdmissionPolicy might enforce replica limits or ensure specific labels are present, while a MutatingAdmissionPolicy can modify resources such as adding a default label to a namespace.

Binding objects link the policy to your cluster and provides scoping. A ValidatingAdmissionPolicyBinding or MutatingAdmissionPolicyBinding connects the policy to specific resources. If you only want to enforce a policy for a specific subset of resources, the binding is where you narrow the scope of the policy (using `matchResources`).

Parameters allow separating configuration for the policy behavior from its definition. Parameter resources refer to Kubernetes resources available in the API. They can be built-in API types (such as ConfigMap), or they can be [custom resources](docs/concepts/extend-kubernetes/api-extension/custom-resources/). A policy binding then uses `spec.paramRef` to reference an actual parameter resource.

If a policy does not require parameters, you leave `spec.paramKind` unspecified.

### CEL expressions

Both kinds of policy rely on an expression language known as Common Expression Language (CEL). Read [CEL in Kubernetes](/docs/reference/using-api/cel/) to learn more.

If you are new to CEL, practice writing a very simple expression, such as `false || true`. You can test CEL expressions in [CEL Playground](https://playcel.undistro.io).

### Policy actions

Each admission policy binding must specify one or more actions to declare how the policy is enforced.

#### ValidatingAdmissionPolicyBinding {#policy-actions-validating}

For ValidatingAdmissionPolicyBinding, the supported `validationActions` are:

Audit : Validation failure is included in the audit event for the API request.

Warn : Va …(trimmed)