Explains Kyverno generate rules to automatically create or clone NetworkPolicies, Roles, and other resources for new and existing Kubernetes Namespaces.
Previously, our platform engineer Alex used Kyverno to bring order to his Kubernetes clusters. He started with validate rules to act as a gatekeeper, ensuring incoming resources met organizational standards. Then he applied mutate rules to inject labels and defaults automatically. Both helped enforce consistency, but a new requirement calls for automatically creating resources — a job for Kyverno generate rules.In this lesson we’ll introduce Kyverno generate rules, which create new resources in response to triggers (for example, when a Namespace is created). We’ll follow Alex’s real-world problem to explain why generate rules are the right approach and how to use them effectively.
Alex’s organization introduced a security mandate: every new Namespace must include a default “deny-all” NetworkPolicy and a standard Role used by their CI/CD pipeline. These are sensible security controls, but Alex has been creating them manually.
Manually watching for Namespace creation and then creating NetworkPolicies and Roles is slow, repetitive, and error-prone. If Alex is busy or forgets, a Namespace could remain unsecured. A validate rule would simply block Namespace creation until the required resources exist — which is not the intended outcome. A mutate rule can only modify the incoming Namespace object; it cannot create separate resources such as a NetworkPolicy or a Role.
The question becomes: how can Alex automate creation of resources when a trigger occurs (for example, on Namespace creation) so that every Namespace automatically receives the mandated NetworkPolicy and Role? Kyverno generate rules solve exactly this problem.
Generate rules let Kyverno create new resources in response to events (like a Namespace creation). This is different from:
validate rules (which block or allow requests), and
mutate rules (which modify the incoming resource).
Use generate when you need Kyverno to produce a separate resource (e.g., a NetworkPolicy, Role, Secret).
This lesson will cover four core generate-rule concepts Alex needs:
Concept
Purpose
When to use
Data source generation
Embed the full YAML manifest inside the policy and generate the resource from that manifest
When you want Kyverno to create a templated resource (e.g., a standard NetworkPolicy) that isn’t stored anywhere else
Clone source
Use a centrally managed “golden” resource (ConfigMap, Secret) as the source to clone into new Namespaces
When multiple Namespaces need the same configuration from a single source of truth
cloneList
Combine multiple clone operations in a single rule to clone a set of resources at once
When you need to populate a new Namespace with several standard resources in one action
Apply to existing resources
Run generate rules against already-created Namespaces to bring them into compliance
When you want to retroactively ensure all Namespaces have the required resources, not just newly created ones
Below is a minimal, illustrative example of a Kyverno ClusterPolicy that uses a generate rule to create a NetworkPolicy when a Namespace is created. This example is simplified to show the structure:
Note: The generate block supports different patterns — embedding a manifest, cloning a named resource, or using cloneList to clone multiple resources. In later sections we’ll show concrete examples for each pattern, plus how to configure generation for existing Namespaces.
Avoid using validate to enforce presence of resources that Kyverno can generate. Blocking Namespace creation is disruptive; instead, prefer generate to create required resources automatically or combine generate with monitoring policies to detect missing resources.
By the end of this lesson you will be able to:
Automatically create NetworkPolicies, Roles, and other resources when Namespaces are created.
Clone centrally managed “golden” resources into multiple Namespaces.
Use cloneList to bundle multiple clone operations.
Apply generation rules to existing Namespaces to bring the cluster into compliance.
