Skip to main content
Previously, we covered JMESPath and the predefined variables. In this lesson we apply that knowledge to one of Kyverno’s most powerful capabilities: preconditions. What is a precondition? A precondition is an additional set of checks that must pass before a rule’s main action (validate, mutate, or generate) is executed. Kyverno evaluates a request in the following order: Only if the resource passes the match and exclude checks does Kyverno evaluate the preconditions. Preconditions use JMESPath expressions (for example, request.object.spec.type) to inspect the incoming resource. If the preconditions evaluate to true, the rule proceeds to its configured action. Think of preconditions as the rule’s gatekeeper.
The image is an introduction to preconditions in Kyverno, outlining the steps for processing a request: checking the match block, exclude block, and preconditions, followed by applying the rule action.
Goal: create a rule that only affects Services of type NodePort.
The image illustrates a simple precondition example with "Alex" having the goal to "create a rule that only affects services of type NodePort."
Example policy skeleton Below is a concise Kyverno rule pattern: it matches all Services, then uses a precondition to restrict execution to Services whose spec.type equals NodePort.
How this works
  • The match block selects Service resources.
  • The preconditions block reads request.object.spec.type and compares it to NodePort.
  • If the resource is a ClusterIP Service, the precondition evaluates to false and the rule is skipped.
  • If the resource is a NodePort Service, the precondition evaluates to true and the rule proceeds to execute its action (validate/mutate/generate).
Best practice: handle missing fields safely Kubernetes resources often contain optional fields. A JMESPath expression that assumes a path exists (for example, a label or spec field) can raise an evaluation error if the path is missing. To avoid such errors and make policies resilient, provide a safe default using the logical OR (||) operator in your expression.
The image explains how to handle non-existent fields using the OR ('||') operator, suggesting it as a solution to provide default values when a field doesn't exist.
When a field may not exist, append || '' (or another safe default) to the JMESPath expression to prevent errors and make your policy resilient.
Example: safely check for a label This expression tries to read the app label and falls back to an empty string if metadata.labels or the app key is absent:
Logical composition: any (OR) vs all (AND)
  • Use any when the precondition should pass if at least one check is true. any implements logical OR across its entries.
  • Use all when every listed condition must be true. all implements logical AND across its entries.
Example: any — apply a rule to a Deployment if color=blue OR app=busybox:
Kyverno evaluates each any entry sequentially and passes the preconditions as soon as one entry is true. Example: all — apply a rule only to Deployments that have animal=cow AND env=qa:
Kyverno evaluates all entries in order; if any entry is false, the all block fails immediately and the rule is skipped. Use all to enforce a strict checklist of conditions. Quick reference: common precondition operators (Refer to the Kyverno documentation for the full list of supported operators and semantics.) Links and references That’s it for this lesson.

Watch Video