Skip to main content
Previously, Alex automated creation of a default NetworkPolicy for every new namespace. Creating resources automatically is helpful, but launch is only the first step — you must also keep generated resources healthy and aligned with the desired state. As a platform engineer, Alex now asks: what happens if a cluster admin accidentally deletes a generated NetworkPolicy while cleaning up? What if someone modifies it and unintentionally opens a security hole? Will a deleted or modified downstream resource become orphaned or drift out of sync? The synchronize option in Kyverno is designed to address these concerns by keeping the policy and its generated resource continuously reconciled.
The image discusses Alex's concern about resource mismatch after automating a NetworkPolicy, highlighting potential issues like accidental deletion, modifications, and orphaned resources. It suggests the need for a solution to keep the cluster's state aligned with the policy.

What synchronize does

synchronize is a boolean flag you add to a generate rule. When set to true, Kyverno establishes an active, continuous link between the policy and the generated downstream resource so the policy remains the single source of truth. Example:
When enabled, synchronize provides three primary behaviors:
  • Self-heal: If the downstream resource is modified or deleted, Kyverno will revert or recreate it to match the policy.
  • Propagate updates: Changes to the policy are applied to the generated resource automatically.
  • Cleanup when the trigger is deleted: If the source (trigger) resource is removed, Kyverno will delete the generated resource during reconciliation (unless you change orphaning behavior — see below).
The image introduces the "synchronize" feature, highlighting two key behaviors: self-healing on mismatches and propagation of policy updates.

Quick comparison: synchronize enabled vs disabled

Below is a compact cheat sheet showing how generated resources behave depending on the synchronize setting. The right column describes the fire-and-forget model (synchronize: false): once the resource is created, the policy no longer manages it — modifications or deletions are not reverted.
The image is a table comparing synchronization behaviors with "synchronize: true" and "synchronize: false" effects, detailing how different actions affect downstream processes.

Orphaning generated resources

Kyverno normally removes generated downstream resources if the policy that created them is deleted. This is usually desirable, but sometimes you may want to retain those resources after removing the policy — for example, when you intend to manage them manually. You can control this with the orphaned flag in the generate block:
  • orphaned: true — leave generated resources intact when the policy that created them is deleted.
  • orphaned: false (default) or omitted — generated resources are deleted when the policy is removed.
The image is a table explaining the effects of the "orphanDownstreamOnPolicyDelete" setting. When set to false, downstream is deleted; when true, downstream is retained.
When synchronize: true is enabled, Kyverno actively enforces the generated resource’s state. Use orphaned: true only when you intentionally want to retain generated resources after removing the policy.

Summary

  • Use synchronize: true to maintain an active, reconciled relationship between a policy and the resources it generates: self-heal, update propagation, and cleanup behavior.
  • Use orphaned: true only when you want to retain generated resources after deleting the policy.
  • These options help prevent drift, accidental deletions, and unintended security regressions when automating resource generation with Kyverno.
Next: clone sources — how to use an existing resource as a template when generating downstream objects.

Watch Video

Practice Lab