Skip to content

Admission Policies#

Kubernetes admission policies let cluster administrators validate or mutate incoming API requests with Common Expression Language (CEL) rules. They run inside the API server, which avoids the operational cost of a webhook server. See Validating Admission Policy and Mutating Admission Policy for the upstream specification.

Lens Desktop groups all admission policy resources under Admission Policies in the Navigator and shows a NEW badge on the group node. All four kinds are cluster-scoped.

Navigator with the Admission Policies group expanded next to a ValidatingAdmissionPolicy detail panel with CEL-highlighted expressions

Kubernetes API support#

Kind API group/version
ValidatingAdmissionPolicy admissionregistration.k8s.io/v1
ValidatingAdmissionPolicyBinding admissionregistration.k8s.io/v1
MutatingAdmissionPolicy admissionregistration.k8s.io/v1
MutatingAdmissionPolicyBinding admissionregistration.k8s.io/v1

When a cluster has not yet promoted a kind to v1, Lens Desktop falls back to v1beta1 or v1alpha1 automatically. See the upstream documentation linked in the intro for the maturity level on your cluster's Kubernetes version.

Where to find admission policies#

Connect to a cluster and open Admission Policies in the Navigator. The group contains:

  • Validating Admission Policies
  • Validating Admission Policy Bindings
  • Mutating Admission Policies
  • Mutating Admission Policy Bindings

Each entry opens a table. The search field filters by name. You can resize, reorder, sort, and hide columns, and export the table as CSV.

Policy and binding model#

Admission policies use a three-part model:

  1. The policy declares the CEL logic (validations or mutations) without selecting any targets.
  2. A parameter resource (optional, a CRD or ConfigMap) supplies tunable values to the policy.
  3. The binding activates the policy against a target set of resources and, for validating policies, selects which validation actions to apply.

A policy only takes effect when at least one matching binding exists. The parameter resource is referenced from the policy through paramKind and from the binding through paramRef.

Validating Admission Policies#

ValidatingAdmissionPolicy declares CEL validation rules that the API server runs against admitted objects.

The list view shows the following columns:

Column Description
Name The policy name.
Validations The number of CEL validation rules in the policy.
Failure Policy The action to take when CEL evaluation errors out: Fail (default) or Ignore.
Age How long the policy has existed.

Open a policy to see two tabs:

  • Validations: every validation rule, match condition, variable, and audit annotation declared on the policy.
  • Bindings: every ValidatingAdmissionPolicyBinding that activates this policy.

In the Validations tab, Lens Desktop renders each section as a drawer item with CEL syntax highlighting:

  • Validations: one drawer item per rule, labelled Validation 1, Validation 2, and so on. Each shows the CEL expression and an optional messageExpression.
  • Match Conditions: one drawer item per condition, labelled Match: \<name>. Each shows the CEL expression that gates whether the policy runs.
  • Variables: one drawer item per declared variable, labelled Variable: \<name>. Each shows the CEL expression that defines the variable.
  • Audit Annotations: one drawer item per annotation, labelled Audit: \<key>. Each shows the CEL valueExpression.

Validating Admission Policy Bindings#

ValidatingAdmissionPolicyBinding activates a ValidatingAdmissionPolicy against a target set of resources and selects the validation actions to apply.

Column Description
Name The binding name.
Policy The ValidatingAdmissionPolicy this binding activates. Click to open the policy.
Validation Actions The actions the API server takes when a validation fails: Deny, Warn, or Audit.
Age How long the binding has existed.

The detail panel shows the bound policy reference, the match resources, and the parameter reference, if any.

Info

Kubernetes forbids combining Deny and Warn in the same binding because the failure would be duplicated in both the API response and the HTTP warning headers. Valid combinations include [Deny], [Warn, Audit], and [Audit].

Mutating Admission Policies#

MutatingAdmissionPolicy declares CEL-based mutations that the API server applies to admitted objects.

Column Description
Name The policy name.
Mutations The number of mutation rules in the policy.
Reinvocation Policy Whether the API server re-runs the policy after other mutations touch the request: Never (default) or IfNeeded.
Failure Policy The action to take when CEL evaluation errors out: Fail (default) or Ignore.
Age How long the policy has existed.

Open a policy to see two tabs:

  • Mutations: every mutation rule, match condition, and variable declared on the policy.
  • Bindings: every MutatingAdmissionPolicyBinding that activates this policy.

In the Mutations tab, Lens Desktop renders each section as a drawer item with CEL syntax highlighting:

  • Mutations: one drawer item per rule, labelled Mutation 1 (ApplyConfiguration) or Mutation 1 (JSONPatch), depending on the patch type. Each shows the CEL expression for the apply configuration or JSON patch.
  • Match Conditions: one drawer item per condition, labelled Match: \<name>.
  • Variables: one drawer item per declared variable, labelled Variable: \<name>.

Info

ApplyConfiguration mutations cannot modify atomic structs, maps, or arrays. Kubernetes rejects them to avoid silently dropping fields not included in the configuration. Use JSONPatch when you need to mutate atomic structures.

Mutating Admission Policy Bindings#

MutatingAdmissionPolicyBinding activates a MutatingAdmissionPolicy against a target set of resources.

Column Description
Name The binding name.
Policy The MutatingAdmissionPolicy this binding activates. Click to open the policy.
Age How long the binding has existed.

The detail panel shows the bound policy reference, the match resources, and the parameter reference, if any.

CEL variables available in expressions#

Admission policy expressions can reference these CEL variables:

Variable Description
object The incoming request object. null for DELETE.
oldObject The existing object. null for CREATE.
request The attributes of the API admission request.
params The parameter resource bound through paramRef. Populated only when the policy declares paramKind.
namespaceObject The namespace of the incoming object. null for cluster-scoped resources.
variables A map of composited variables defined in the policy, accessed as variables.<name>.
authorizer A CEL authorizer for permission checks on the request principal.

CEL syntax highlighting#

Every CEL expression in an admission policy is rendered with theme-aware syntax highlighting:

  • Keywords and macros appear in the primary accent colour, bold.
  • Policy variables appear in the warning colour.
  • Strings and numbers appear in the success colour.
  • Operators appear in the critical colour.
  • Punctuation appears muted.

The same renderer powers CEL match conditions on webhook configurations. See Validating Webhook Configs and Mutating Webhook Configs.

See also#