Demo Any and All Statements

In this lesson we explore Kyverno ClusterPolicy resource filters: any (logical OR) and all (logical AND). These filters let you target resources (for example, Pods) using flexible or strict matching logic and enforce validation rules such as required labels. What you’ll do:

Create a ClusterPolicy that uses match.any (logical OR).
Test the policy by creating Pods that match one or both conditions.
Update the policy to use match.all (logical AND) and re-run tests to observe the difference.

The any filter behaves like a logical OR: the rule applies if at least one condition matches. The all filter behaves like a logical AND: the rule applies only if every condition matches.

These policies use validationFailureAction: enforce, which means matching requests will be blocked by the admission webhook if validation fails. Apply policies cautiously in production clusters.

Step 1 — Policy using `any` (logical OR)

Create a policy file named check-label.yaml with the following content. This ClusterPolicy enforces that when a Pod matches either selector (type: database OR purpose: testing), it must have an app label — otherwise the creation is rejected.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-label-app
spec:
  validationFailureAction: enforce
  rules:
    - name: check-label-app
      match:
        any:
          - resources:
              kinds:
                - Pod
            selector:
              matchLabels:
                type: database
          - resources:
              kinds:
                - Pod
            selector:
              matchLabels:
                purpose: testing
      validate:
        message: "The label app is required."
        pattern:
          metadata:
            labels:
              app: "?*"

Apply the policy and confirm it’s ready:

kubectl apply -f check-label.yaml
# Output:
kubectl get cpol check-label-app
# Example output:
# NAME             ADMISSION   BACKGROUND   READY   AGE   MESSAGE
# check-label-app  true        true         True    11s   Ready

Testing scenarios (with match.any):

Pod with type=database but no app label — should be blocked because it satisfies the first any condition.

kubectl run my-pod --image=nginx --labels="type=database"
# Expected error:
# Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:
# resource Pod/default/my-pod was blocked due to the following policies
#
# check-label-app:
#   check-label-app: 'validation error: The label app is required. rule check-label-app failed at path /metadata/labels/app/'

Pod with purpose=testing but no app label — should be blocked because it satisfies the second any condition.

kubectl run my-pod2 --image=nginx --labels="purpose=testing"
# Expected error:
# Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:
# resource Pod/default/my-pod2 was blocked due to the following policies
#
# check-label-app:
#   check-label-app: 'validation error: The label app is required. rule check-label-app failed at path /metadata/labels/app/'

Summary for match.any: matching either selector triggers validation.

Step 2 — Switch to `all` (logical AND)

To require both selectors be present before enforcing the label, replace the match.any block with match.all. The effect: the rule applies only when the Pod matches both type: database and purpose: testing. Updated check-label.yaml (key change: all instead of any):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-label-app
spec:
  validationFailureAction: enforce
  rules:
    - name: check-label-app
      match:
        all:
          - resources:
              kinds:
                - Pod
            selector:
              matchLabels:
                type: database
          - resources:
              kinds:
                - Pod
            selector:
              matchLabels:
                purpose: testing
      validate:
        message: "The label app is required."
        pattern:
          metadata:
            labels:
              app: "?*"

Apply the updated policy:

kubectl apply -f check-label.yaml
# Output:
kubectl get cpol check-label-app
# Example output:
# NAME             ADMISSION   BACKGROUND   READY   AGE    MESSAGE
# check-label-app  true        true         True    11s    Ready

Re-run tests for the three scenarios with match.all:

Pod with only type=database (no purpose) — policy should NOT apply, Pod created successfully.

kubectl run pod-only-type --image=nginx --labels="type=database"
# Expected output:
# pod/pod-only-type created

Pod with both type=database and purpose=testing but missing app — policy applies, creation blocked.

kubectl run test-pod --image=nginx --labels="type=database,purpose=testing"
# Expected error:
# Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:
# resource Pod/default/test-pod was blocked due to the following policies
#
# check-label-app:
#   check-label-app: 'validation error: The label app is required. rule check-label-app failed at path /metadata/labels/app/'

Pod with type=database, purpose=testing, and app=testing — all matching conditions satisfied and validation passes; Pod created.

kubectl run test-pod-with-app --image=nginx --labels="type=database,purpose=testing,app=testing"
# Expected output:
# pod/test-pod-with-app created

Quick comparison

Filter	Logical meaning	Example match that triggers validation	Typical use case
`match.any`	OR — at least one condition must match	`type=database` OR `purpose=testing` (either label triggers enforcement)	Broad validation across multiple categories
`match.all`	AND — every condition must match	Both `type=database` AND `purpose=testing` must be present	Narrow validation when multiple attributes must coincide

Summary

match.any (OR): The rule applies if at least one listed resource filter matches the resource. Use this to enforce rules across multiple possible resource selector conditions.
match.all (AND): The rule applies only when every listed resource filter matches the resource. Use this to target a narrow subset of resources that must satisfy every criterion.

References and further reading:

Kyverno documentation — ClusterPolicy and match conditions: https://kyverno.io/docs/
Kubernetes admission controllers: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

Use any when you want to validate resources that meet any of multiple criteria. Use all when validation should only apply to resources that satisfy every listed condition.

Demo Any and All Statements

Step 1 — Policy using `any` (logical OR)

Step 2 — Switch to `all` (logical AND)

Quick comparison

Summary

Watch Video

Practice Lab

​Step 1 — Policy using any (logical OR)

​Step 2 — Switch to all (logical AND)

​Quick comparison

​Summary

Watch Video

Practice Lab

Step 1 — Policy using `any` (logical OR)

Step 2 — Switch to `all` (logical AND)

Quick comparison

Summary