Guide to using the Kyverno CLI and kyverno apply to locally validate Kubernetes policies and manifests for fast feedback, enforcement simulation, and CI integration.
In the introduction we saw Alex’s frustration with the slow feedback loop: edit YAML, apply to a cluster, then wait to discover the resource is non-compliant. This lesson fixes that by letting you validate policies and manifests locally — fast.What is the Kyverno CLI?The Kyverno CLI is a standalone command-line tool for authoring, testing, and validating Kyverno policies and Kubernetes resources outside of a cluster. It runs the same evaluation engine as the in-cluster Kyverno admission controller, so you can get accurate, instant feedback on your workstation or inside CI/CD.
Key benefit: local policy testing and “shift left”One of the most valuable features — and the focus of this lesson — is the CLI’s ability to test policies against one or more resources entirely locally. You do not need cluster access to check whether a manifest complies with a policy. This reduces debugging time, avoids failed deploys, and is ideal for adding checks to CI pipelines.
InstallationInstall the Kyverno CLI using the method that best fits your platform and workflow:
Clone and build: https://github.com/kyverno/kyverno — run make build
For this lesson we’ll assume the kyverno executable is on your PATH (or you run kubectl kyverno if installed via krew).The command we’ll master: kyverno applykyverno apply simulates the Kyverno admission controller locally. It accepts policy files and one or more resource manifests, evaluates resources against the rules, and prints a concise summary indicating pass/fail status.
Run the CLI to verify the pod against the policy.Failing run (when the label is missing):
$ kyverno apply policy.yaml --resource pod.yamlApplying: 3 policy rule(s) to 1 resource(s)...policy require-purpose-label -> resource default/Pod/my-app-pod failed:1 - require-purpose-label validation error: You must have label `purpose` with value `production`. rule require-purpose-label failed at path /metadata/labels/pass: 0, fail: 1, warn: 0, error: 0, skip: 0
Why does the output say “Applying: 3 policy rule(s)…” when the file only defines one rule?Kyverno generates Autogen Rules for related controllers (Deployments, StatefulSets, Jobs, CronJobs, etc.) based on your Pod rule. This ensures coverage for resources created by controllers without requiring you to write duplicate rules. The CLI reports each generated rule when evaluating.
Kyverno’s Autogen Rules expand a single Pod rule into additional rules for common controllers (Deployments, StatefulSets, Jobs, CronJobs, etc.), which is why a single policy can appear as multiple evaluated rules.
Fix the manifest and re-runAlex adds the required label to his Pod:pod.yaml (updated):
Number of resources that passed all evaluated rules
fail
Number of resources that failed at least one rule
warn
Number of resources that triggered a warning rule
error
Any internal errors during evaluation
skip
Rules or resources skipped (e.g., when policy conditions don’t match)
Wrap upUsing kyverno apply lets you shift left: validate policies and manifests locally for immediate feedback, integrate checks into CI/CD, and reduce the cycle time and frustration of trial-and-error cluster deployments. In this lesson we covered the basic kyverno apply workflow and demonstrated a simple enforcement policy. The CLI supports many additional flags and advanced scenarios (multiple policies, globbing, JSON/summary outputs) that you’ll see in the next lesson.
In the next lesson we’ll explore advanced kyverno apply flags, multi-file testing, automated CI integration, and output formats for scripting and reporting.
