Skip to main content
In the previous lesson we met Alex and introduced conditional and equality anchors to express if-then logic across peer and child elements. In this follow-up, Alex must solve three new, more nuanced problems. Each requires a different Kyverno anchor:
  • Ensure every Pod includes at least one container using the nginx image (presence within a list).
  • Forbid use of hostPath volumes entirely (absolute negation).
  • Enforce that images pulled from the corporate registry require a specific imagePullSecret, but skip the rule for public images (rule-level gating).
This article explains the three anchors tailored for those needs, with practical examples and a comparison to common wildcard patterns.
This guide focuses on Kyverno anchors: existence (^), negation (X), and global (<()), showing how each solves a specific policy requirement. Use the examples as starting points and adapt patterns to your organization’s naming and image conventions.

​
Quick anchor summary

For full reference, see the Kyverno docs: Kyverno Policy Patterns.

​
1) Existence anchor: ensure at least one container uses nginx

Alex wants to guarantee that each Pod contains at least one container using the nginx image, but he does not want to force all containers to use it. Use the existence anchor (^) to treat the containers list as a set and require at least one element to match the following pattern. Example pattern (snippet used inside a validate rule’s pattern):
Behavior:
  • Kyverno iterates the containers array and passes validation as soon as it finds one container whose image equals nginx:latest.
  • Other containers may use any image; they are not required to match.
Contrast with a wildcard-based pattern that inadvertently requires every container to match:
Behavior:
  • This pattern uses a wildcard for name, but it still enforces that each array item (every container) must match image: nginx:latest.
  • If any container uses a different image (e.g., a Python app), the Pod will fail validation.
Use the existence anchor when you want a flexible presence check; use the wildcard pattern only when you want every element to conform.

​
2) Negation anchor: forbid hostPath volumes

To outright ban hostPath volumes (a critical security rule), use the negation anchor X. This anchor fails the validation when the named key exists in the object being checked. Example pattern that iterates all volumes and forbids hostPath:
Notes:
  • The X(hostPath): "null" line means: if the hostPath key exists on any volume, fail.
  • The anchor does not evaluate the value of hostPath (e.g., /data); it only checks the presence of the key.
  • This produces a deterministic deny: hostPath cannot be used at all.
Forbidding hostPath is a common hardening practice. Make sure you coordinate with app owners because legitimate workloads that require node-local access might need alternate approaches (e.g., CSI drivers).

​
3) Global anchor: gate the rule itself for corporate registry images

Alex wants a rule that applies only when a Pod pulls images from the corporate registry (corp.reg.com). If the Pod uses public images (Docker Hub, etc.), the rule should be skipped. Use the global anchor <(...) to create a gate — evaluate the rest of the pattern only when the condition is true. Pattern example:
How it works:
  1. Kyverno first evaluates the condition in the global anchor: does the container image match corp.reg.com/*?
  2. If the condition is false (e.g., redis:latest from Docker Hub), Kyverno skips this pattern for that container — no failure.
  3. If the condition is true, Kyverno enforces the rest of the pattern — in this case, the Pod must include imagePullSecrets with name: my-registry-secret.
This creates an explicit “if and only if” rule: only images from the corporate registry trigger the secret requirement.

​
Example: a Pod that will be rejected

Trace a failing request to see the global anchor in action: Example Pod that will be blocked:
Evaluation:
  • Step 1: The global anchor matches because the container image is from corp.reg.com.
  • Step 2: The gate opens and Kyverno checks for imagePullSecrets with name: my-registry-secret.
  • The Pod only has other-secret, so the pattern fails and Kyverno rejects the Pod with the configured message.

​
Putting it all together

Use the right anchor for each scenario:
  • Existence anchor (^) — presence in arrays without overconstraining: ensure at least one nginx container.
  • Negation anchor (X) — absolute denial for sensitive keys: forbid hostPath.
  • Global anchor (<() ) — gate the rule so it only applies when a condition is met: require an imagePullSecret for corporate-registry images.
Example policy skeletons and the pattern snippets above are designed to be embedded inside a full Kyverno ClusterPolicy or Policy validate rule. Test policies in a staging cluster and iterate with clear message fields so developers get actionable feedback.

Watch Video