Skip to main content
Previously we gave Alice a set of anchors to express complex conditional logic in Kyverno. Now Alex faces a related but different problem: a resource can be correctly configured in two distinct ways. How can Kyverno accept either configuration without writing two separate rules? This article explains how to use Kyverno’s anyPattern to express a logical OR inside a single validation rule so the rule accepts a resource if it matches any one of the supplied patterns. Scenario: enforce non-root containers
  • Requirement: All containers must run as a non-root user.
  • Two valid developer models:
    • Set runAsNonRoot: true at the Pod-level securityContext (pod default).
    • Or set runAsNonRoot: true on every container (container-level).
The image presents a challenge related to running containers as a non-root user, with two configuration options for developers: setting runAsNonRoot: true at the Pod level or individually for each container.
Both approaches are valid, but a single Kyverno pattern typically describes one structural variant. Combining both structures into one pattern is either impossible or results in a very complex pattern. anyPattern solves this cleanly by providing multiple alternative patterns; Kyverno passes validation if any pattern matches. Why this policy must handle two cases
  • Problem 1 — override risk:
    • A Pod-level default (spec.securityContext.runAsNonRoot: true) can be overridden by a container setting securityContext.runAsNonRoot: false. The policy must prevent containers from disabling a safe pod default.
    Example container override:
  • Problem 2 — missing default:
    • If there is no pod-level runAsNonRoot default, every container (and initContainer) must explicitly set runAsNonRoot: true. The policy must validate per-container declarations.
    Example without pod default:
Policy intent
  • Accept the Pod if either:
    1. The Pod has spec.securityContext.runAsNonRoot: true and no container (or initContainer) sets runAsNonRoot: false, or
    2. Every container and initContainer explicitly sets securityContext.runAsNonRoot: true.
This either-or logic is exactly why anyPattern exists. How anyPattern works
  • Place anyPattern inside a rule’s validate block.
  • anyPattern accepts a YAML list of alternative patterns.
  • Kyverno evaluates patterns sequentially; validation succeeds on the first matching pattern. The resource is rejected only if it fails to match every pattern in the list.
The image introduces "anyPattern," explaining its behavior as a logical OR across patterns and its use case for validating fields defined in multiple locations.
A Kyverno rule must use either a single pattern or anyPattern. Do not combine pattern and anyPattern in the same rule.
Policy fragment (solution)
  • The example below shows two alternative patterns inside anyPattern:
    • Pattern A: Enforce a pod-level default and prevent container overrides.
    • Pattern B: Require per-container runAsNonRoot: true when no pod default exists.
Pattern breakdown Notes and tips
  • Use the optional presence marker (=) when you need to express conditional requirements for keys that may or may not exist (e.g., =(initContainers)).
  • Keep message descriptive so users know how to fix failures (pod-level default vs. per-container settings).
  • anyPattern is especially useful when the same valid configuration can be expressed in multiple Kubernetes locations (e.g., pod vs container).
References That’s it—using anyPattern keeps your validation rules concise while allowing multiple valid configuration models for the same requirement.

Watch Video