Mutating Admission Policy [page]deterministic

This page provides an overview of _MutatingAdmissionPolicies_. MutatingAdmissionPolicies allow you to change what happens when someone writes a change to the Kubernetes API. If you want to use declarative policies just to prevent a particular kind of change to resources (for example: protecting platform namespaces from deletion), [ValidatingAdmissionPolicy](/docs/reference/access-authn-authz/validating-admission-policy/) is a simpler and more effective alternative.

## What are MutatingAdmissionPolicies?

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

Mutating admission policies use the Common Expression Language (CEL) to declare mutations to resources. Mutations can be defined either with an *apply configuration* that is merged using the [server side apply merge strategy](/docs/reference/using-api/server-side-apply/#merge-strategy), or a [JSON patch](https://jsonpatch.com/).

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

## What resources make a policy

A policy is generally made up of three resources:

• The MutatingAdmissionPolicy describes the abstract logic of a policy (think: "this policy sets a particular label to a particular value").

• A _parameter resource_ provides information to a MutatingAdmissionPolicy to make it a concrete statement (think "set the `owner` label to something like `company.example.com`"). Parameter resources refer to Kubernetes resources, available in the Kubernetes API. They can be built-in types or extensions, such as a [CustomResourceDefinition](#gloss:CustomResourceDefinition) (CRD). For example, you can use a ConfigMap as a parameter.
• A MutatingAdmissionPolicyBinding links the above (MutatingAdmissionPolicy and parameter) resources together and provides scoping. If you only want to set an `owner` label for `Pods`, and not other API kinds, the binding is where you specify this mutation.

At least a MutatingAdmissionPolicy and a corresponding MutatingAdmissionPolicyBinding must be defined for a policy to have an effect.

> Note: Names ending in `.static.k8s.io` are reserved for [manifest-based admission control](/docs/reference/access-authn-authz/manifest-admission-control/) and cannot be used for API-based policies or bindings. This reservation is enforced when the `ManifestBasedAdmissionControlConfig` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/#ManifestBasedAdmissionControlConfig) is enabled.

If a MutatingAdmissionPolicy does not need to be configured via parameters, simply leave `spec.paramKind` in MutatingAdmissionPolicy not specified.

## Getting Started with MutatingAdmissionPolicies

Mutating admission policy is part of the cluster control-plane. You should write and deploy them with great caution. The following describes how to quickly experiment with Mutating admission policy.

### Create a MutatingAdmissionPolicy

The following is an example of a MutatingAdmissionPolicy. This policy mutates newly created Pods to have a sidecar container if it does not exist.

The `.spec.mutations` field consists of a list of expressions that evaluate to resource patches. The emitted patches may be either [apply configurations](#patch-type-apply-configuration) or [JSON Patch](#patch-type-json-patch) patches. You cannot specify an empty list of mutations. After evaluating all the expressions, the API server applies those changes to the resource that is passing through admission.

To configure a mutating admission policy for use in a cluster, a binding is required. The MutatingAdmissionPolicy will only be active if a corresponding binding exists with the referenced `spec.policyName` matching the `spec.name` of a policy.

Once the binding and policy are created, any resource request that matches the `spec.matchConditions` of a policy will trigger …(trimmed)