Policies and rules, YAML manifests, admission controllers, OCI images
ClusterPolicy — Cluster-wide Kyverno policy; Policy is the namespaced version. A policy is a list of rules; each rule has a match/exclude block and one action: validate, mutate, generate or verifyImages. Docs
Admission webhooks — Kyverno runs as mutating and validating admission webhooks. The API server sends each matching request to Kyverno, which mutates and/or allows or rejects it before it is stored. Docs
Policies as YAML — No new language: patterns overlay the resource YAML you already know. A validate pattern like `spec: containers: - image: "!*:latest"` reads like the resource it checks. JMESPath and CEL add expressions when needed. Docs
OCI image references — registry/repository:tag@digest — what image rules match and verify. Kyverno parses every container image into registry, path, name, tag and digest, exposed as the built-in images.containers / images.initContainers variables for policies to check. Docs
Installation, Configuration, and Upgrades (18%)
Helm install, Kyverno CRDs, controller flags, RBAC, high availability, upgrades
Helm install — helm install kyverno kyverno/kyverno -n kyverno --create-namespace. The chart installs the admission, background, cleanup and reports controllers; values tune replicas, resources and flags. Docs
Kyverno CRDs — ClusterPolicy, Policy, PolicyException, CleanupPolicy, PolicyReport…. CRDs are installed with the chart and must be upgraded along with it. Docs
Kyverno controllers — admission, background, cleanup and reports controllers, each with its own flags. Flags (e.g. --enablePolicyException, --protectManagedResources) are set via Helm values per controller. Docs
Kyverno RBAC — Generate and mutate-existing rules need extra permissions for the resources they touch. Aggregated ClusterRoles (label rbac.kyverno.io/aggregate-to-background-controller) grant controllers access to new kinds. Docs
High availability — Run 3+ admission controller replicas so the webhook never blocks the API. With failurePolicy Fail, an unavailable webhook blocks matching requests — HA and PodDisruptionBudgets matter. Docs
Kyverno CLI (12%)
apply, test, jp, installing the CLI
kyverno apply — Runs policies against resource files (or a cluster) without admission. `kyverno apply policy.yaml --resource pod.yaml` — great in CI to fail builds on violations. Docs
kyverno test — Declarative tests: a kyverno-test.yaml lists policies, resources and expected results. Each result asserts pass/fail/skip for a policy, rule and resource — unit tests for policies. Docs
kyverno jp — Evaluates JMESPath expressions the way Kyverno does. `kyverno jp query -i pod.yaml "spec.containers[].image"` — debug an expression before putting it in a policy. Docs
Installing the CLI — kubectl krew install kyverno, a release binary, or brew install kyverno. Used as `kubectl kyverno …` when installed through krew. Docs
Applying Policies (10%)
Applying in cluster, resource selection, common rule settings
match / exclude — Select resources by kinds, names, namespaces, labels, operations and users. any/all blocks combine conditions; exclude carves out exceptions like kube-system. Docs
failureAction — Enforce blocks the request; Audit allows it and records a violation. Set per validate rule (older policies used spec.validationFailureAction). Start in Audit, review reports, then Enforce. Docs
Background scans — background: true re-checks existing resources and reports violations. Admission only sees new requests; background scanning finds resources that were already there. Docs
Writing Policies (32%)
validate, mutate, generate, verifyImages, preconditions, variables, autogen, cleanup, CEL
validate rule — Checks resources with a pattern, anyPattern, deny conditions or CEL. Pattern operators: * wildcard, ? single char, ! negation, | or, and ranges; =() anchors make a check conditional. Docs
mutate rule — Changes resources with patchStrategicMerge or patchesJson6902. +(key) adds a field only if it is missing, e.g. a default imagePullPolicy. mutateExisting rules can patch resources already in the cluster. Docs
generate rule — Creates resources when something happens — e.g. a NetworkPolicy in every new namespace. data or clone sources; synchronize: true keeps the generated resource in sync and recreates it if deleted. Docs
verifyImages — Checks image signatures and attestations (Sigstore cosign, Notary). Can also mutate tags to digests (mutateDigest) so the verified image is the one that runs. Docs
Preconditions — Extra conditions a rule needs before it applies (any/all with operators). e.g. only when request.operation is CREATE, or a label value equals "prod". Docs
Variables & API calls — {{request.object.metadata.name}}, context entries, configMap and apiCall lookups. Context can load data from ConfigMaps, the Kubernetes API or external services and use it in JMESPath expressions. Docs
Auto-gen rules — A rule written for Pods is automatically extended to Deployments, CronJobs…. Kyverno generates matching rules for Pod controllers so violations are caught at the Deployment, not just its Pods. Controlled by the pod-policies.kyverno.io/autogen-controllers annotation. Docs
CleanupPolicy — Deletes matching resources on a cron schedule (or via a TTL label). ClusterCleanupPolicy is cluster-scoped; the cleanup.kyverno.io/ttl label deletes a single resource after a duration. Docs
CEL — Common Expression Language — the same language as ValidatingAdmissionPolicy. validate.cel.expressions like "object.spec.replicas <= 5"; newer ValidatingPolicy types are CEL-first. Docs
Policy Management (10%)
Policy reports, PolicyExceptions, Kyverno metrics
PolicyReport — Per-namespace (and cluster) results: pass, fail, warn, error, skip. `kubectl get policyreport -A` shows how existing resources fare — the output of Audit mode and background scans. Docs
PolicyException — Exempts specific resources from specific rules, without editing the policy. Must be enabled (--enablePolicyException) and is often limited to a namespace so creating exceptions can be controlled. Docs
Kyverno metrics — Prometheus metrics: policy results, admission latency, policy changes. e.g. kyverno_policy_results_total and kyverno_admission_review_duration_seconds, scraped from each controller. Docs
Practice questions
What is Kyverno?
Answer: A policy engine for Kubernetes where policies are Kubernetes resources. Policies can validate, mutate, generate and verify images, and clean up resources.
Which policy kind is namespaced?
Answer: Policy. A Policy applies only to resources in its own namespace.
Which language do Kyverno pattern-based policies use?
Answer: Kubernetes-style YAML with overlay patterns (plus JMESPath and CEL expressions). Gatekeeper uses Rego; Kyverno avoids a new language.
What happens if a matching validate rule fails with failureAction Enforce?
Answer: The API request is rejected with the rule’s message. Audit would allow it and report the violation.
Which webhook types does Kyverno register with the API server?
Answer: Validating admission webhooks; Mutating admission webhooks. Mutation happens before validation in the admission chain.
Which admission phase runs first in Kubernetes?
Answer: Mutating admission. Mutations are applied, then validating webhooks see the final object.
How do Kyverno rules select which resources they apply to?
Answer: match (and optional exclude) blocks. match/exclude support kinds, names, namespaces, selectors, operations and subjects.
What does a Kyverno rule’s `match.any` mean?
Answer: The rule applies if any of the listed filters matches. match.all requires all filters to match.
Which image reference part does Kyverno’s images.containers.<name>.tag hold for "nginx:1.27"?
Answer: 1.27. Kyverno also parses registry, path, name and digest.
Which wildcard matches any string in a Kyverno pattern?
Answer: *. ? matches a single character.
What does the pattern `image: "!*:latest"` require?
Answer: The image must not use the latest tag. ! negates the wildcard pattern, so any value ending in :latest fails validation.
Which rule type is evaluated by the background controller for existing resources?
Answer: Generate rules (and mutate-existing). The admission controller handles admission requests; the background controller handles async work.
Where can Kyverno policies be stored and distributed besides Git?
Answer: As OCI artifacts in a registry. Policies are plain YAML, so any versioned store works.
What is Kyverno’s relationship with Kubernetes ValidatingAdmissionPolicy?
Answer: Kyverno can use CEL and can generate/manage ValidatingAdmissionPolicies. Newer Kyverno policy types are CEL-based.
Which Helm repository and chart install Kyverno?
Answer: helm repo add kyverno https://kyverno.github.io/kyverno/ and install kyverno/kyverno. The separate kyverno-policies chart installs Pod Security Standard policies.
Which chart installs a ready-made set of Pod Security Standard policies?
Answer: kyverno/kyverno-policies. You can choose baseline or restricted via values.
How many admission controller replicas are recommended for high availability?
Answer: 3 or more. Plus a PodDisruptionBudget so the webhook stays available.
Why must Kyverno CRDs be upgraded together with the controllers?
Answer: New controller versions expect new CRD schemas and fields. Follow the upgrade notes for each release.
Which namespace does Kyverno usually exclude from its own webhooks to avoid deadlocks?
Answer: The kyverno namespace (plus system namespaces configured as filters). A broken webhook should not block Kyverno from restarting.
What is the resourceFilters configuration used for?
Answer: Telling Kyverno to ignore certain kinds/namespaces entirely (e.g. Events). It is configured in the kyverno ConfigMap.
What does the webhook failurePolicy Ignore mean?
Answer: If Kyverno is unavailable, requests are allowed without policy checks. Fail is safer but requires high availability.
Which controller generates PolicyReports?
Answer: The reports controller. Each controller can be scaled and configured separately.
Which controller executes CleanupPolicies?
Answer: The cleanup controller. It runs on the policies’ schedules.
How do you give the background controller permission to generate a new resource kind?
Answer: A ClusterRole labelled to aggregate to the background controller’s role. Use the rbac.kyverno.io/aggregate-to-background-controller label.
What is the safe upgrade order for Kyverno?
Answer: Read release notes, back up policies, upgrade CRDs and the chart together, one version step as advised. Some upgrades require migration steps.
Which flag set exposes Kyverno metrics for Prometheus?
Answer: Metrics are exposed by default on each controller’s metrics port (configurable via Helm). ServiceMonitors can be enabled in the chart.
How do you protect resources generated by Kyverno from manual edits?
Answer: Enable protection of managed resources (e.g. --protectManagedResources). Only Kyverno can then modify them.
Why give Kyverno resource requests and limits explicitly?
Answer: Admission latency and availability depend on it having enough CPU and memory. Large clusters need more resources for reports and background scans.
Which CLI command applies policies to resources in a live cluster without admission?
Answer: kyverno apply <policy> --cluster. Without --cluster it applies to resource files.
Which file does `kyverno test` look for in a directory?
Answer: kyverno-test.yaml. It lists policies, resources and expected results.
What does a result entry in kyverno-test.yaml specify?
Answer: policy, rule, resources and the expected result (pass/fail/skip). Mutate tests can also compare against patchedResource.
How do you test a mutate rule with the CLI?
Answer: Provide patchedResources in kyverno-test.yaml and compare the output. The CLI checks the mutated resource matches the expected one.
How does the CLI supply values that normally come from the cluster (e.g. API calls) during tests?
Answer: A values file (--values-file / -f) with variables and context data. This keeps tests offline and deterministic.
Which command parses a JMESPath expression to check its syntax?
Answer: kyverno jp parse. kyverno jp query evaluates an expression against input.
Which command lists Kyverno’s custom JMESPath functions?
Answer: kyverno jp function. Custom functions include to_upper, base64_decode, time functions and more.
Which output format makes `kyverno apply` print a policy report?
Answer: --policy-report. Useful to see results the way the cluster would report them.
How is the Kyverno CLI used with kubectl?
Answer: As a kubectl plugin: kubectl kyverno …. Installed via krew or as a standalone binary.
Which match filter applies a rule only on CREATE operations?
Answer: operations: [CREATE] in the resource filter. UPDATE, DELETE and CONNECT can also be selected.
How do you apply a rule only to namespaces labelled env=prod?
Answer: match resources.namespaceSelector with matchLabels env: prod. namespaceSelector filters by the namespace’s labels.
How do you exempt cluster admins from a rule?
Answer: exclude with clusterRoles: [cluster-admin] (or subjects). Exclusions can target users, groups, roles and service accounts.
What does `background: false` on a policy do?
Answer: The policy applies only to admission requests, not to existing resources. Policies using request-specific data (like userInfo) need background: false.
Why can’t a background-scanned rule use request.userInfo?
Answer: Background scans have no admission request, so there is no user information. Set background: false for such rules.
How do you send a warning to the user instead of blocking, without Audit reports?
Answer: Use failureAction Audit with emitWarning (or the rule’s warning settings). Audit allows the request; warnings show in kubectl output.
Which setting applies a validate rule only to new objects and skips UPDATEs of existing ones that already violated it?
Answer: Using operations: [CREATE] or a precondition on request.operation. Otherwise legacy objects could become impossible to update.
Which validate style requires at least one of several patterns to match?
Answer: anyPattern. pattern requires a single pattern to match.
What does the `=()` equality anchor do in a validate pattern?
Answer: Applies the inner check only if the field exists. =(hostPath): … checks hostPath only when present.
What does the `^()` existence anchor check?
Answer: That at least one element of a list matches the pattern. Useful for "at least one container must…" rules.
What does the `<()` global anchor do?
Answer: If the condition inside fails, the whole rule is skipped (not failed). It acts like a condition embedded in the pattern.
Which operator in a pattern checks a numeric range?
Answer: A range like "1-10" (or >, <, >=, <=). Quantities such as "<=2Gi" are also supported.
What does a deny condition in a validate rule do?
Answer: Rejects the request when its conditions are true. validate.deny.conditions with any/all and operators.
Which operators are available in Kyverno conditions?
Answer: Equals / NotEquals; AnyIn / AllNotIn; GreaterThan / LessThan. Duration and quantity comparisons are also supported.
How do you add a label team: platform to every new Deployment?
Answer: A mutate rule with patchStrategicMerge setting metadata.labels.team: platform. Use +(team) to only add it when missing.
When would you use patchesJson6902 instead of patchStrategicMerge?
Answer: For precise operations such as adding to a specific list index or removing a field. RFC 6902 operations: add, remove, replace, move, copy, test.
What does mutateExisting (mutate with targets) do?
Answer: Mutates already-existing resources when a trigger resource changes. It runs in the background controller and needs RBAC for the targets.
What does a generate rule with `clone` do?
Answer: Copies an existing resource (e.g. a Secret) into the target namespace. data defines the resource inline instead.
What happens when synchronize: true and the generated resource is deleted?
Answer: Kyverno recreates it. Changes to the source (clone) or policy data also propagate.
Which generate setting removes generated resources when the trigger is deleted (synchronized)?
Answer: They are deleted along with the trigger when synchronize is true. With synchronize: false, generated resources are left alone.
Which verifyImages fields describe what to check?
Answer: imageReferences (which images); attestors (keys or keyless identities). Attestations (e.g. SBOM, provenance) can also be verified.
What does verifyImages mutateDigest: true do?
Answer: Replaces the tag with the verified digest in the Pod spec. Ensures the verified image is the one that runs.
How does a keyless verifyImages rule identify the signer?
Answer: By the certificate subject (identity) and issuer from Sigstore Fulcio. It also checks the Rekor transparency log.
How do you look up data from a ConfigMap in a rule?
Answer: A context entry of type configMap, then {{name.data.key}}. Context entries load data before the rule runs.
How do you call the Kubernetes API from a rule (e.g. count Pods in a namespace)?
Answer: A context entry with apiCall (urlPath and jmesPath). apiCall can also call external services.
Which variable holds the new object in an admission request?
Answer: request.object. request.oldObject holds the previous version on UPDATE.
Which variable gives the user who made the request?
Answer: request.userInfo. Also serviceAccountName and serviceAccountNamespace for service accounts.
How do you provide a default when a variable may be missing?
Answer: JMESPath default with ||, e.g. {{ request.object.metadata.labels.team || 'none' }}. Missing variables otherwise cause rule errors.
Which annotation turns off auto-generation of Pod controller rules?
Answer: pod-policies.kyverno.io/autogen-controllers: none. Or list only the controllers you want.
Which CEL variable refers to the object being validated in a Kyverno CEL expression?
Answer: object. oldObject, request and params are also available.
What does a ClusterCleanupPolicy need besides match?
Answer: A schedule (cron) and optional conditions. Its ServiceAccount needs delete permissions for the kinds.
Which value formats does the cleanup.kyverno.io/ttl label accept?
Answer: A duration (e.g. 1h) or an absolute time (ISO 8601). Unrecognized formats trigger a warning.
What is a precondition used for in a mutate or generate rule?
Answer: Running the rule only when conditions on the request or object hold. E.g. only when a label has a specific value.
Which report kind holds results for cluster-scoped resources?
Answer: pass; fail; skip. warn and error are the other two.
How do you scope who can create PolicyExceptions?
Answer: Allow exceptions only in specific namespaces (exceptionNamespace) and control RBAC there. Exceptions weaken policies, so their creation must be governed.
Which fields does a PolicyException require?
Answer: exceptions (policy and rule names); match (which resources are exempt). Conditions can further restrict an exception.
Which metric would show how many requests a policy blocked?
Answer: kyverno_policy_results_total filtered by result="fail" and the enforce mode. Labels include policy, rule, result and resource kind.
How do you list violations across all namespaces?
Answer: kubectl get policyreport -A (and clusterpolicyreport). kubectl get polr is the short name.
Why are PolicyReports useful during an Enforce rollout?
Answer: They show existing violations in Audit mode before you start blocking. Fix or except violators, then switch to Enforce.
How does Kyverno see resources as they are created?
Answer: The API server calls it as a mutating and validating admission webhook. Kyverno registers admission webhooks; background controllers handle existing resources.
Which rule types can a Kyverno ClusterPolicy rule have?
Answer: validate; mutate; generate; verifyImages. Each rule has exactly one of the four actions.
Kyverno’s webhook uses failurePolicy Fail. Why run several admission controller replicas?
Answer: If the webhook is unavailable, matching API requests are rejected. Fail-closed webhooks block requests when down, so availability matters.
A generate rule must create RoleBindings, but Kyverno gets "forbidden". What fixes it?
Answer: Grant the background controller permissions via an aggregated ClusterRole. Kyverno can only create what its controllers are allowed to; aggregate-to labels extend their roles.
In CI, you want to fail the build if manifests violate your policies — no cluster available. Which command?
Which CLI command runs declarative tests with expected pass/fail results?
Answer: kyverno test. kyverno test reads a kyverno-test.yaml listing policies, resources and expected results.
You are rolling out a new policy and want violations recorded but not blocked. Which setting?
Answer: failureAction: Audit. Audit allows the request and reports the violation in PolicyReports.
The policy should apply everywhere except kube-system. How?
Answer: An exclude block matching namespace kube-system. match selects resources; exclude carves out exceptions.
Add imagePullPolicy: IfNotPresent only when the container does not already set one. Which mutate syntax?
Answer: The +() add anchor: +(imagePullPolicy): IfNotPresent. +() adds the field only if it is absent, leaving existing values alone.
Every new namespace must get a default-deny NetworkPolicy automatically. Which rule type?
Answer: generate (with synchronize: true). generate creates new resources in response to a trigger such as a Namespace being created.
You wrote a validate rule matching Pods. Why are Deployments also rejected?
Answer: Auto-gen rules extend Pod rules to Pod controllers like Deployments. Autogen catches violations at the controller level so you do not get endless failing ReplicaSets.
One legacy workload must be exempt from a single rule. Best practice?
Answer: A PolicyException naming that policy, rule and resource. Exceptions are narrow, separately reviewable and leave the policy untouched.
Where do you see which existing resources fail an Audit-mode policy?
Answer: PolicyReport / ClusterPolicyReport resources. Reports collect results from admission (Audit) and background scans.