> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Demo Any and All Statements
> Explains Kyverno ClusterPolicy match.any and match.all filters to apply OR or AND resource matching and enforce Pod label validation
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.
```yaml theme={null}
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:
```bash theme={null}
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`):
1. Pod with `type=database` but no `app` label — should be blocked because it satisfies the first `any` condition.
```bash theme={null}
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/'
```
2. Pod with `purpose=testing` but no `app` label — should be blocked because it satisfies the second `any` condition.
```bash theme={null}
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`):
```yaml theme={null}
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:
```bash theme={null}
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`:
1. Pod with only `type=database` (no `purpose`) — policy should NOT apply, Pod created successfully.
```bash theme={null}
kubectl run pod-only-type --image=nginx --labels="type=database"
# Expected output:
# pod/pod-only-type created
```
2. Pod with both `type=database` and `purpose=testing` but missing `app` — policy applies, creation blocked.
```bash theme={null}
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/'
```
3. Pod with `type=database`, `purpose=testing`, and `app=testing` — all matching conditions satisfied and validation passes; Pod created.
```bash theme={null}
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/](https://kyverno.io/docs/)
* Kubernetes admission controllers: [https://kubernetes.io/docs/reference/access-authn-authz/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.