Skip to main content
Alex can easily clone a single golden Secret into new namespaces. But his platform team needs more than one resource per namespace — they maintain a standard onboarding bundle of configurations (a database credential Secret, an API key Secret, and an application ConfigMap) in a central staging namespace. Creating a separate clone rule for each resource works, but it’s not scalable: it’s repetitive, error-prone, and requires policy edits whenever the standard bundle changes. Kyverno’s cloneList solves this by enabling cloning of multiple resources from a single source namespace in one generate rule.
The image outlines "Alex's Onboarding Problem," highlighting challenges with managing secrets, such as database credentials, API keys, and application ConfigMaps, due to repetitive and risky processes.
Instead of using generate.clone to copy a single resource, generate.cloneList lets you define multiple source resources to be cloned from a single namespace. This is ideal for shipping a standard bundle of Secrets and ConfigMaps into newly-created namespaces.
The image describes the "cloneList" object, used to clone multiple resources using the command "generate.cloneList" from a single source namespace, and includes an illustration of a person interacting with a flowchart on a digital screen.

​
cloneList fields

The cloneList object includes three primary fields: Using a selector avoids copying every Secret and ConfigMap from the source namespace — only those labeled for cloning will be included in the standard bundle.
Using selector lets the platform team add or remove resources from the standard onboarding bundle by updating labels in the staging namespace — the Kyverno policy itself doesn’t need to change.

​
cloneList example structure

A minimal cloneList structure looks like this:

​
Full Kyverno rule: clone standard configs into new namespaces

This rule triggers on new Namespace creation and clones the selected Secrets and ConfigMaps from the staging namespace into the newly-created namespace. The synchronize: true option keeps generated resources synchronized with their sources.
Cloning Secrets copies sensitive data into target namespaces. Ensure you have appropriate RBAC, Secrets encryption (e.g., KMS/provider secrets encryption), and audit controls in place to protect sensitive material.

​
Why this approach is better

  • Scalability: one policy handles the whole onboarding bundle instead of one policy per resource.
  • Flexibility: platform engineers can change the bundle by adjusting labels in the staging namespace — no policy edits required.
  • Consistency: synchronize: true ensures generated resources stay aligned with their golden sources.

​
Next steps and references

This article covered how to generate resources from clone sources using cloneList. Next topics to explore include applying generate rules to existing namespaces and handling lifecycle concerns (updates, deletions, and synchronization conflicts). This pattern helps teams onboard new namespaces quickly and reliably by delivering a standard set of configuration objects from a central staging location.

Watch Video

Practice Lab