Skip to main content
In this lesson we show how to embed an entire Kubernetes resource manifest directly inside a Kyverno generate rule using the data source. This lets Kyverno create downstream resources (for example, a NetworkPolicy) automatically when a trigger event occurs (for example, creating a Namespace). Why this matters: embedding the resource in the policy ensures the desired resource is created consistently and can be reconciled over time when you enable synchronization.

​
Trigger vs Source — the two parts of a generate rule

Every generate rule has two distinct responsibilities:
  • The trigger — when should the rule run? (Defined in match or via existing when reconciling existing resources.)
  • The source — what should the rule create? (Either data for an embedded manifest or clone to copy an existing cluster resource.)
When you want Kyverno to create a new resource from a manifest embedded in the policy, you use the data source. Alternatively, clone copies an existing resource in the cluster. These two options are mutually exclusive — a rule can only use one.
The image is an informational slide titled "Alex's Plan: Understanding the Basics," discussing triggers for rule execution, either on admission of new resources or on existing resources.
The image is a slide from a presentation titled "Alex's Plan: Understanding the Basics," explaining two concepts: "Data" (focusing on defining a resource inside a policy) and "Clone" (copying an existing resource from a cluster).
data and clone are mutually exclusive: a single generate rule must use either data (embedded manifest) or clone (copy from cluster), not both.
A common term in Kyverno documentation is downstream resource — this is the resource that Kyverno generates (for example, a ConfigMap, Secret, or NetworkPolicy). When we say Kyverno manages downstream resources, we mean the resources generated by generate rules.

​
Generate rule anatomy

At a high level, a generate rule contains:
  • match (or existing) — defines the trigger (the incoming resource that activates the rule).
  • generate — describes the downstream resource identity (kind, apiVersion, name, namespace) and contains the source (data or clone).
Use the table below to quickly map concept to YAML location: Here is a minimal example that demonstrates these parts (focus on the rules block):
In this example:
  • match triggers the rule when a Namespace is created.
  • generate declares the NetworkPolicy to create and contains data for the NetworkPolicy spec.
  • Note the use of {{request.object.metadata.name}} to place the generated NetworkPolicy in the newly created Namespace.

​
Prerequisite: permissions for the Kyverno background controller

Generate rules are executed by Kyverno’s background controller. By default, that controller only has a limited set of RBAC permissions. If you want Kyverno to create resource types not already allowed (for example, NetworkPolicy), grant the background controller the necessary permissions. Kyverno supports cluster role aggregation. Instead of editing built-in Kyverno roles, create a separate ClusterRole that grants the required verbs for the resource and add the aggregation label rbac.kyverno.io/aggregate-to-background-controller: "true". Kubernetes will merge (aggregate) these rules into the background controller role.
The image is a slide explaining the prerequisite of granting permissions for Kyverno to create a NetworkPolicy, which involves setting RBAC permissions and creating a ClusterRole with a specific label.
Create a ClusterRole like this (note: apiGroups uses the group networking.k8s.io, not networking.k8s.io/v1):
By adding the label rbac.kyverno.io/aggregate-to-background-controller: "true", Kubernetes will aggregate these rules into Kyverno’s background controller ClusterRole so you don’t need to modify Kyverno’s built-in roles.

​
Complete example — create a default deny-all NetworkPolicy for new Namespaces

Below is a practical generate rule that creates a deny-all NetworkPolicy in every newly created Namespace. The synchronize: true field creates a durable link between the policy and the generated resource: when the policy changes, Kyverno will reconcile the generated resources to match the policy (preventing configuration drift).
The image is about "Solving Alex's Challenge: Automating the Network Policy" and includes a character named Alex stating a plan to create a 'deny-all' network policy using a generate rule.
Use this rules snippet in a policy:
With this single policy rule, every new Namespace automatically receives the default-deny-all NetworkPolicy at creation time.
When you enable synchronize: true, the generated resources are continuously reconciled to the policy data block. If you plan to allow manual edits to generated resources, consider the implications carefully — synchronization will overwrite deviations.

​
Quick recap

The image is a summary diagram explaining three concepts: Trigger, Source, and Downstream Resource within a policy framework. Each concept is briefly defined with associated descriptions.
The image is a summary slide with points on the "Kyverno Background Controller" being responsible for executing generate rules and instructions on granting permissions for generation by creating a ClusterRole with a specific label.

​
Next steps and further reading

  • To learn more about synchronize behaviors, refer to the Kyverno docs on generate rules.
  • For RBAC aggregation and ClusterRole design patterns, review Kubernetes RBAC aggregation documentation.
  • Kyverno docs: https://kyverno.io/docs/
With these fundamentals, you can author generate rules that embed resource blueprints directly in policies and automate consistent, cluster-wide resource creation. This sets the stage for more advanced generation scenarios (templating, conditional generation, or cloning existing resources).

Watch Video