Use a mutation policy to modify Kubernetes resources when pods are deployed in your clusters.

Using VMware Tanzu Mission Control, you can make the deployments to your clusters more consistent by implementing policies that add or modify resources in those deployments before they are admitted. Mutation policies, implemented using OPA Gatekeeper, can help prevent the deployment of pods that don't conform to your specifications.

You can use a mutation policy to alter the following types of Kubernetes resource properties:
  • annotations
  • labels
  • pod security properties

A mutation policy can alter (mutate) the pod specification (podspec) to enforce conformance to the policy. When a pod is deployed to the cluster, the policy mutates the podspec as defined in the policy before admitting the request to deploy the pod.

Mutating Labels and Annotations

You can create a mutation policy to specify a label to be applied to a Kubernetes resource before it is admitted to a cluster. When a deployment is evaluated for admission, the policy creates the label (key/value pair) only if it does not already exist. If there is a pre-existing label on the resource, the policy cannot change it. Also, because the policy evaluates deployments only during admission, mutations implemented by the policy can be altered manually after admission.

For more information about how OPA Gatekeeper handles label and annotation mutations, see Mutation: AssignMetadata in the OPA Gatekeeper documentation.

Evaluation and Precedence of Mutation Policies

Mutation policies can be applied in the clusters hierarchy (infrastructure view) in Tanzu Mission Control, and they are inherited down through the hierarchy. You can read more about that in Pod Security Management in VMware Tanzu Mission Control Concepts.

When multiple mutation policies are applied to a cluster, through either direct or inherited policies, they are evaluated as follows:
  • Mutation policies are run against the podspec starting with those applied to the cluster, then those inherited from the cluster group, and finally those inherited from the organization.
  • If there are multiple mutation policies at any level of the hierarchy, they are run in alphanumeric order.
Because a mutation policy can overwrite changes applied by a previously run mutation policy, the order in which they are run is significant.

When a workload is deployed to a cluster that has both mutation policies and security policies, first the mutation policies are evaluated and applied, mutating the podspec as specified. Then, after all mutations have been applied, the security policies are evaluated to determine if the podspec is conformant to allow deployment.