Skip to main content
In earlier lessons we covered what Kubernetes is and how to install a cluster. Now we move to the most powerful part of Kyverno: policies. Kyverno policies express the rules you want Kubernetes to enforce across your cluster. This article introduces the main building blocks, shows how policies are structured, and demonstrates how a platform engineer (Alex) uses them to automate governance at scale.
The image illustrates the concept of "Heart of Kyverno," showing a progression from policies on the left to an icon representing infrastructure or systems on the right, linked by a simple arrow.
We won’t exhaust every option here, but you’ll learn the core pieces and how they fit together so you can start writing effective policies. Meet Alex — platform engineer Alex manages multiple Kubernetes clusters and must keep them secure, consistent, and easy for developers to use. Developers continuously push new workloads, so manual checks are impractical. Kyverno lets Alex codify and automate the guardrails.
The image shows a person named Alex managing Kubernetes clusters with a note indicating he wants to automate governance.
Common governance goals Alex needs to enforce:
  • Ensure resources include a cost-center label for chargeback and tracking.
  • Inject annotations automatically when missing.
  • Block insecure or unsigned container images.
  • Auto-create a default NetworkPolicy for every new namespace.
The image is a slide titled "Meet Alex Again" that lists challenges, including ensuring resources have labels for cost tracking, adding annotations, blocking insecure container images, and generating default resources like namespaces.
Manually enforcing these policies across dozens or hundreds of clusters is error-prone — Kyverno automates it. Policy structure overview A Kyverno policy is a YAML object containing one or more rules. Each rule has two main responsibilities:
  • Target selection — decide which resources the rule applies to (via match and optional exclude blocks).
  • Action — choose a single action type per rule: validate, mutate, generate, or verifyImages.
The image illustrates the structure of a policy with a focus on target selection, detailing components like match and exclude rules, and actions such as validate, mutate, generate, and verify images.
A rule’s match/exclude determines the scope (kinds, namespaces, label selectors, users, operations), and then the rule performs exactly one action on those matched resources.
The image is a diagram illustrating the structure of a policy, focusing on defining rules and actions like validating, mutating, and generating resources. It includes elements such as matching, excluding, and verifying images, and lists related components like resources, operations, and user roles.
Quick summary table of rule types Validate rules (gatekeeping) validate rules act as admission checks. If a resource does not meet the rule’s criteria, the API server rejects it with a clear error message. Example: disallow containers that run as root. This validate rule matches Pods on creation/update and enforces securityContext.runAsNonRoot: true:
The image highlights a challenge involving "validating resources," with an issue where developers deploy containers as the 'root' user, posing a security risk.
Mutate rules (automatic corrections) mutate rules let Kyverno modify an incoming resource so it conforms to your policies — without blocking the developer. Example: automatically add a cost-center label to Deployments if it’s missing:
The image illustrates a challenge related to forgetting to add required labels, like a 'cost-center' label, which makes tracking spending difficult. It features an icon labeled "Alex" along with this challenge description.
When a developer submits the Deployment, Kyverno injects the label before the object is persisted. Generate rules (provision defaults) generate rules create resources automatically in response to other events — ideal for provisioning default guardrails. Example: create a default NetworkPolicy whenever a Namespace is created. This ensures namespaces are created with network restrictions without relying on each team to add them.
The image shows a challenge involving a task for creating a default network policy to restrict traffic when a new namespace is created for a team. It includes an icon labeled "Alex" and a checkmark indicating the requirement.
Generate rules are commonly used for: NetworkPolicy, ResourceQuota, LimitRange, service accounts, or other namespace-level defaults. VerifyImages rules (supply-chain protection) One of the strongest defenses against supply-chain attacks is to verify container images at admission. verifyImages rules check signatures and attestors (trusted signers) so only images built and signed by your CI/CD are allowed. Example: require signed images from ghcr.io/my-org/* and validate signatures using a trusted public key:
The image features a question about ensuring the integrity of container images built by a CI/CD pipeline, asked by a character named Alex, under the heading "Verifying Images."
Image verification is a critical security control. Misconfiguration can block valid deployments or fail to prevent unsigned images. Test verifyImages policies in a staging cluster and ensure your CI/CD signs images with the correct keys before enforcing in production.
Policy scope: Policy vs ClusterPolicy Kyverno provides two policy object types to control scope:
  • Policy (namespaced): The policy only applies to resources inside the namespace where it’s created. Use for team-specific rules, e.g., a payments team policy defined in the payments namespace.
  • ClusterPolicy (cluster-wide): The policy applies across all namespaces in the cluster. Use for global security or compliance checks, e.g., blocking privileged containers or enforcing image signature verification cluster-wide.
The rules, match/exclude syntax, and actions are identical between Policy and ClusterPolicy — only the scope differs.
The image compares "Policy" and "ClusterPolicy." "Policy" is a namespaced resource applying within a specific namespace, while "ClusterPolicy" is a cluster-wide resource applying across all namespaces.
Best practices (brief)
  • Start with Policy in a staging namespace to test rules, then promote to ClusterPolicy.
  • Use clear message fields in validate rules so developers get actionable errors.
  • Prefer mutate and generate when you can auto-correct without blocking developer velocity.
  • Use verifyImages to enforce image provenance; integrate signing into CI/CD pipelines.
Tip: Use labels and selectors in match blocks to target only the workloads you intend to manage (for example, match.resources.kinds: ["Deployment"] and match.resources.namespaces: ["production"]).
Resources and further reading This lesson gave you a concise introduction to Kyverno’s core rule types: validate, mutate, generate, and verifyImages. In subsequent lessons we’ll dive deeper into each rule type with hands-on examples, real-world patterns, and production-ready configurations.

Watch Video