Kyverno Certified Associate cheat sheet

Kyverno is a Kubernetes-native policy engine: policies are Kubernetes resources, evaluated by an admission controller, with no separate policy language or Rego.

Policy types: ClusterPolicy is cluster-scoped; Policy is namespaced and its rules apply only to resources in that same namespace.

Rule types: validate (allow/deny or audit), mutate (patch existing resources), generate (create derived resources), verifyImages (check image signatures and attestations).

A rule contains match (required), exclude (optional), and exactly one of the action blocks; a rule with both mutate and validate content is invalid.

match/exclude use resource selectors: kinds, names, namespaces, selector (label selector), annotations, operations (CREATE, UPDATE, DELETE, CONNECT).

Admission review flow: API server sends AdmissionReview to the webhook, Kyverno evaluates matching rules, and returns allowed or denied with a message; audit mode records PolicyReport entries instead of blocking.

PolicyReport (namespaced) and ClusterPolicyReport (cluster-scoped) aggregate per-resource results with pass, fail, warn, error, and skip counts.

Background scanning re-evaluates existing resources on a schedule (background scan interval) so drift and pre-existing violations appear in reports.

Kyverno runs as a Deployment in the kyverno namespace; controllers include admission, background, reports, cleanup, and a webhook registration component.

Helm install: helm repo add kyverno https://kyverno.github.io/kyverno/ then helm install kyverno kyverno/kyverno -n kyverno --create-namespace, optionally pinning --version.

Install modes: standard HA (default, multiple replicas), standalone with a single replica, and a separate reports-server for scaled deployments; choose based on cluster size and load.

Key Helm values: replicaCount, admissionController.replicas, backgroundController.replicas, reportsController.replicas, cleanupController.replicas, and resource requests/limits per controller.

ConfigMap kyverno in the kyverno namespace holds runtime settings such as resourceFilters, webhooks (namespaceSelector, timeoutSeconds), and generateExisting behavior.

resourceFilters entries use a filter structure with any/all/exclude blocks; a common pattern excludes system namespaces and Kyverno's own namespace from admission processing.

Policy exceptions are declared as Exception resources (kyverno.io/v2) or via a ConfigMap of exception entries; exceptions are matched by policy name and rule names.

Upgrades use Helm (helm upgrade) with CRD updates applied separately; check the release notes for CRD changes because Helm does not upgrade CRDs automatically.

High availability requires at least three replicas for the admission controller and a PodDisruptionBudget; the webhook failurePolicy and timeoutSeconds control behavior when Kyverno is unavailable.

Verify installation with kubectl get pods -n kyverno, kubectl get clusterpolicies, and the Kyverno CLI test command against a known policy.

The CLI binary is kyverno; install via Homebrew, container image, or release archive, and match its version to the cluster's Kyverno version for accurate testing.

kyverno apply --resource evaluates policies against local manifests and prints per-rule pass/fail results without a cluster.

kyverno test runs declarative test suites: a kyverno-test.yaml lists policies, resources, and expected results (result: pass/fail/skip/warn).

kyverno test supports user variables, values files, and expected mutated/generated resource comparison via the patchedResources or generatedResources fields.

kyverno jp query evaluates JMESPath expressions against a JSON/YAML document; kyverno jp parse tokenizes an expression for debugging.

kyverno create generates policy, test, or exception scaffolding (kyverno create policy, kyverno create test) to speed authoring.

kyverno apply --cluster downloads policies from a live cluster and applies them to local resources; --policy-report emits a PolicyReport-style YAML output.

kyverno migrate converts legacy or PodSecurityPolicy policies into Kyverno policy manifests, useful during cluster upgrades.

The CLI does not run the admission webhook; generate rules are simulated only when --resource input includes the trigger resource and the CLI can compute the derived object.

Apply with kubectl apply -f policy.yaml; validation failures surface as API errors, and a rejected rule blocks the whole policy from being stored.

Use kubectl get clusterpolicy -o yaml to confirm the stored spec and kubectl get policyreport -A to see enforcement results.

Dry-run first: kubectl apply --dry-run=server triggers the admission webhook so you can see whether the policy would be enforced.

Audit versus enforce: set spec.validationFailureAction to Audit to record failures without blocking, or Enforce to deny the request; the default is Enforce.

Policy ordering is not guaranteed; mutate rules run before validate rules in the admission pipeline, but rules within a policy are evaluated independently.

generate rules create resources only when the trigger matches; use generateExisting: true to backfill resources that already exist, and synchronize: true to keep generated resources in sync.

Policy exceptions are matched by policy name and rule names and let specific resources bypass rules without editing the policy; exceptions are cluster-scoped or namespaced.

Reporting: results appear on the resource's PolicyReport; use kubectl get clusterpolicyreport and label selectors to filter by policy or result.

Validate rules use either a deny block with conditions and a message, or a pattern block; the pattern is an overlay match where omitted fields are ignored and null means the field must be absent.

Pattern operators: (X) for negation, X|Y for alternatives, ? for a single character, * for zero or more characters, and anchors such as <, > for start/end.

Conditions use JMESPath expressions with operators Equals, NotEquals, In, AnyIn, AllIn, GreaterThan, LessThan, and matching operators like Length and Any.

Common variables: request.operation, request.userInfo.username, request.userInfo.groups, request.object, request.oldObject, and serviceAccountName for the admission requester.

Mutate rules use patchesJSON6902 (explicit add/replace/remove operations) or patchesStrategicMerge; a strategic merge patch is simpler but cannot remove list entries reliably.

Mutate supports foreach to iterate over arrays, and anchors to reference values produced by earlier patches; use patchStrategicMerge with +(field) to add without overwriting existing values.

generate rules specify apiVersion, kind, name, namespace, and data; use clone or cloneList to copy an existing resource, and synchronize to keep it aligned.

verifyImages rules reference an imageReferences pattern, attestors (keys, certificates, keyless), and required attestations; a failure denies the pod when in Enforce mode.

Policy variables use JMESPath in {{ }} expressions; test expressions with kyverno jp query before embedding them in a policy.

Version policies in Git and deliver them with GitOps (Argo CD or Flux); Kyverno policies are plain Kubernetes objects, so drift is detected like any other resource.

Separate policy sets by scope: cluster-wide baseline ClusterPolicies, namespace-scoped Policies for team rules, and Exceptions for approved deviations.

Policy exceptions should be time-bounded and reviewed; record the justification in annotations and remove exceptions when the underlying issue is fixed.

PolicyReports are regenerated by the reports controller; use them for dashboards and alerts, and do not treat them as an audit log of every admission request.

Use kyverno test in CI to validate policies against fixture resources before merging, and run kyverno apply against representative manifests.

Upgrade discipline: read release notes for CRD and API version changes, back up policies with kubectl get clusterpolicy -o yaml, and re-run tests after upgrading.

Use label selectors and annotations on policies for ownership and classification; the reports controller can filter by these labels when generating reports.

Cleanup policies (CleanupPolicy and ClusterCleanupPolicy) delete stale resources on a schedule; they are separate from admission rules and must be managed as their own policy set.

Monitor the admission controller's latency and error rate; a slow webhook adds latency to every matching API request, so scope match blocks narrowly.