apply Command Part 3

Earlier we looked at how the Kyverno apply command validates resources with a clear pass/fail result. In this lesson we’ll focus on how the Kyverno CLI previews the exact effects of mutate and generate rules so you can see the concrete changes Kyverno would perform in a real cluster.

Previewing mutate rules

Start with a mutate policy that injects default resource requests into containers that lack them:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-resources
spec:
  rules:
    - name: add-default-requests
      match:
        any:
          - resources:
              kinds:
                - Pod
      mutate:
        foreach:
          - list: "spec.containers[]"
            patchStrategicMerge:
              spec:
                containers:
                  - (name): "{{ element.name }}"
                    resources:
                      requests:
                        +(memory): "100Mi"
                        +(cpu): "100m"

This policy uses foreach to iterate over each container in a Pod. The +(memory) and +(cpu) anchors indicate “add only if not present” — existing resources.requests remain untouched. Here’s a simple NGINX Pod manifest that lacks a resources block:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
spec:
  containers:
    - name: nginx
      image: nginx:1.14.2

When Kyverno runs in a cluster this policy will mutate the Pod prior to creation so the container receives the default requests. Locally, the Kyverno CLI can render exactly that mutated YAML so you can inspect changes before applying them. Run:

kyverno apply policy.yaml --resource pod.yaml

Example CLI output (truncated for clarity):

$ kyverno apply policy.yaml --resource pod.yaml
Applying 1 policy rule(s) to 1 resource(s)...
policy add-default-resources applied to default/Pod/nginx-demo:
apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
  namespace: default
spec:
  containers:
    - name: nginx
      image: nginx:1.14.2
      resources:
        requests:
          cpu: 100m
          memory: 100Mi
---
Mutation:
Mutation has been applied successfully.
pass: 1, fail: 0, warn: 0, error: 0, skip: 0

To save the mutated manifest to a file (handy for testing, CI, or debugging), add --output (or -o):

kyverno apply policy.yaml --resource pod.yaml --output mutated-pod.yaml

Advanced mutate: target vs trigger resources

Some policies are evaluated against one resource (the trigger) but mutate another resource (the target). For example, a policy that reacts to a ConfigMap create event and mutates an existing Secret. In this case provide both manifests to the CLI so Kyverno can compute the mutation. Example policy (watches ConfigMap, mutates an existing Secret):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: mutate-existing-secret
spec:
  rules:
    - name: mutate-secret-on-configmap-create
      match:
        any:
          - resources:
              kinds:
                - ConfigMap
      mutate:
        patchStrategicMerge:
          metadata:
            labels:
              foo: bar
        targets:
          - apiVersion: v1
            kind: Secret
            name: secret-1
            namespace: staging

When testing locally:

Use --resource to pass the trigger (the ConfigMap manifest).
Use --target-resource to pass the current state of the Secret that Kyverno should mutate.

Example CLI invocation:

kyverno apply mutate-secret-policy.yaml --resource trigger-configmap.yaml --target-resource secret-1.yaml

Use --target-resource when the object to be mutated is not the same as the trigger resource. This lets the CLI load the target’s current state and show the exact mutation that would be performed.

Previewing generate rules

Generate rules create new resources (for example, a NetworkPolicy when a Namespace is created). To preview a generate rule, pass the generate policy and the triggering resource with --resource. Kyverno CLI will print the full YAML of the generated resource (not a modified version of the trigger). This output helps you verify template variable substitution, metadata, and the final manifest. You can also save the generated YAML using --output.

Quick reference: common kyverno apply flags

Flag	Purpose	Example
`--resource`	Pass the trigger resource manifest to evaluate policies against	`--resource pod.yaml`
`--target-resource`	Provide the current state of the object to be mutated when the target differs from the trigger	`--target-resource secret-1.yaml`
`--output`, `-o`	Save the mutated or generated manifest to a file	`--output mutated-pod.yaml`

Recap

The Kyverno CLI previews the exact outcome of mutate policies by rendering the full mutated resource YAML.
For generate rules the CLI prints the generated resource YAML so you can validate the final manifest.
Use --output (or -o) to write results to a file for testing or pipelines.
When the mutated object differs from the trigger, pass its current state with --target-resource so the CLI can compute the mutation precisely.

The image is a summary with a gradient background, detailing four points related to CLI operations: preview mutations, preview generations, save results, and test mutate existing. Each point includes a brief description and is numbered with colorful labels.

This is it for this lesson.

apply Command Part 3

Previewing mutate rules

Advanced mutate: target vs trigger resources

Previewing generate rules

Quick reference: common kyverno apply flags

Recap

Watch Video

Practice Lab

​Previewing mutate rules

​Advanced mutate: target vs trigger resources

​Previewing generate rules

​Quick reference: common kyverno apply flags

​Recap

Watch Video

Practice Lab

Previewing mutate rules

Advanced mutate: target vs trigger resources

Previewing generate rules

Quick reference: common kyverno apply flags

Recap