Skip to main content
Previously we covered the basic structure of preconditions and how to use the any and all resource filters. In this lesson we’ll dig into the operators that make preconditions powerful, and walk through several practical, real-world examples you can reuse in your Kyverno policies. The focus is on comparing values robustly — from exact matches to set membership, quantities, and time/duration comparisons. Why this matters: well-crafted preconditions let you scope policy application precisely (for example, only certain service accounts or pods with small memory requests), reducing false positives and enabling safer enforcement.

​
Operator categories

Operators fall into four broad types. Use the category and operator that best matches the shape of the data you’re comparing.
The image describes four types of operators: Equality, Set-Based, Numeric/Quantity, and Time-Based, each with specific functions for comparisons and checks.

​
AnyIn (set-based) example

Use AnyIn when you want a policy to apply only if a value appears in a predefined list. The example below restricts the rule to Namespace creation requests initiated by one of two service accounts.
  • match selects Namespace resources.
  • preconditions uses the predefined variable {{serviceAccountName}}.
  • AnyIn verifies that the service account name is in the allowed list.
This evaluates to true only when the request originates from build-default or build-base, giving a simple, readable restriction to approved service accounts.

​
Numeric / quantity example

Kyverno’s numeric/quantity operators understand Kubernetes resource units, letting you compare values like 512Mi or 1Gi directly. Use these operators to enforce policies based on resource requests or limits.
  • match selects Pod resources.
  • preconditions reads the first container’s memory request via a JMESPath-style variable.
  • LessThan compares the memory request to 1Gi.
Numeric and quantity operators understand Kubernetes resource units such as Ki, Mi, Gi, etc., so you can compare memory/CPU values directly.

​
Wildcard and regex string matching

Pattern matching is useful for fields like hostnames, image names, or labels. Use Matches / NotMatches with regular expressions to include or exclude patterns. Example: apply a policy to any Ingress that points to an external (non-company) domain.
  • match selects Ingress resources.
  • preconditions evaluates the first rule host from spec.rules[0].host.
  • NotMatches with a regex excludes hosts matching the company domain pattern *.mycompany.com.
Because the operator is NotMatches and the regex represents *.mycompany.com, the precondition is true only when the host does not match the company domain — effectively targeting external hosts.
When using regex in preconditions, remember to escape special characters (for example, . becomes \\. in YAML/regex) and validate your expression with a regex tester. Incorrect escaping can cause unexpected behavior or silent mismatches.

​
Using message to debug failing preconditions

When policies have multiple preconditions (especially OR/AND combinations), it can be hard to know which one failed. Add a message to any precondition — if that expression evaluates to false, Kyverno prints the message in its logs. Think of this as a lightweight debug print for policy logic. Example: a ConfigMap policy with two preconditions, each providing a clear failure message.
If data.food is cheese but data.day is tuesday, Kyverno logs will include “The day is not Monday.” This quickly pinpoints the failing precondition and speeds troubleshooting.

​
Quick reference: common patterns

That’s it for this lesson — use these operators and patterns to make Kyverno preconditions precise, readable, and easier to debug.

Watch Video