kyverno apply: Test Kyverno Policies Offline
kyverno apply evaluates one or more Kyverno policies against resource manifests without a cluster and reports pass, fail, warn, error, and skip counts.
The Kyverno CLI lets you shift admission checks left: run the exact ClusterPolicy your cluster enforces against a manifest in CI, so a PR that would be rejected at admission fails the build instead.
What it does
kyverno apply loads the policy files you pass and evaluates them against the resources given by --resource (or a file/glob). It prints a summary of pass/fail/warn/error/skip. With --policy-report it emits a PolicyReport resource; with a non-zero failure count it exits 1 (use --audit-warn to treat Audit results as warnings).
Common usage
# apply a policy to a manifest
kyverno apply policy.yaml --resource deployment.yaml
# apply a directory of policies to a directory of resources
kyverno apply policies/ --resource ./manifests
# emit a machine-readable policy report
kyverno apply policy.yaml --resource deployment.yaml --policy-reportOptions
| Flag | What it does |
|---|---|
| --resource <path> | Resource file, directory, or glob to test; repeatable |
| --policy-report | Output results as a PolicyReport YAML |
| --cluster | Evaluate against resources in the live cluster |
| --values-file <file> | Supply variables/context for policy substitution |
| --audit-warn | Report Audit-mode failures as warnings, not errors |
| -t, --resource-type | Limit evaluation to a resource kind |
In CI
Run kyverno apply on rendered manifests as a required check so admission-time rejections surface in the PR. Vendor the same policy YAML your cluster uses to keep local and cluster verdicts identical. A --values-file provides the variable context (like namespace labels) the policy expects offline.
Common errors in CI
The summary line reads "pass: 1, fail: 1, warn: 0, error: 0, skip: 0" and the process exits 1 when fail > 0. "Error: failed to load policy" means malformed policy YAML. "variable substitution failed for rule ... : could not find" means the policy references context (like a ConfigMap) that is absent offline; supply it with --values-file. "skip" counts usually mean the resource kind did not match the policy match block.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes