Deleting a Kyverno ClusterPolicy removed every NetworkPolicy it generated. Why, and how do you avoid that?

## Why the objects disappeared A synchronized generate rule does not fire and forget. Kyverno keeps a relationship between the policy, the trigger and the downstream object so that it can reconcile drift, and that same relationship defines lifecycle. Two deletions cascade: - **Delete the trigger** and the downstream goes with it. This is the benign direction: the namespace that owns the NetworkPolicy is being deleted anyway, and an ownerReference back to the trigger lets ordinary Kubernetes garbage collection do the work. - **Delete the policy** and the downstream objects it manages are cleaned up too. This is the direction that surprises people, and it is the one in the question. The design intent is reasonable. If a generator is uninstalled, leaving hundreds of orphaned objects that nothing owns, nothing reconciles and nobody can explain is its own kind of mess. Kyverno's default is that uninstalling the rule uninstalls its output. ## Why this particular blast radius is worse than it looks The object being removed matters. A ResourceQuota vanishing is a capacity problem you will notice. A default-deny NetworkPolicy vanishing is a **fail-open** event: in Kubernetes, a namespace with no NetworkPolicy selecting a pod allows all traffic to it. So a change that looks like tidying up policy YAML - deleting a superseded ClusterPolicy, renaming one, or letting a delivery tool prune a resource that dropped out of a directory - can flip an entire cluster from segmented to flat, with no denial, no failed pipeline and no alert. Nothing was blocked, because the mechanism here is creation, not gating. The rename case deserves calling out on its own. A generate rule's downstream is tied to the policy that owns it, so renaming the ClusterPolicy is not an edit; it is a delete plus a create. The old copies go, and the new ones arrive on the next reconcile, with a gap in between. ## The controls, in the order you should reach for them **1. Decouple the lifecycle where you actually want the objects to outlive the rule.** `generate.orphanDownstreamOnPolicyDelete: true` tells Kyverno to leave the downstream resources in place when the policy is deleted. Set it on guardrail generators that must not disappear, and set it *before* the day you need it, not during the change that removes the policy. The tradeoff is real: the surviving objects are now unmanaged, so you have accepted a cleanup obligation in exchange for not failing open. **2. Sequence the decommission deliberately.** When you genuinely are retiring a generator, do it in steps rather than with one `kubectl delete`: confirm what the policy owns, orphan or convert the downstream copies first, verify a sample namespace still has the objects, then remove the rule. Treat it like removing a controller, not like deleting a config file. **3. Restrict who can delete the policy.** The ClusterPolicy resource is now a cluster-wide security control. Write access to it - including whatever delivery mechanism applies it - should sit with the platform team and be as guarded as the RBAC that lets Kyverno's background controller create Secrets in every namespace in the first place. **4. Do not let the guardrail live only in the generated object.** Generation supplies the NetworkPolicy; it does not enforce that one exists. A separate validate rule that rejects workloads in a namespace lacking the expected policy, or a periodic report over namespaces, means the fail-open state is detected rather than assumed impossible. Two independent mechanisms fail independently. ## What to say when asked how you would find out Before deleting anything, you want to know what a policy owns. Generated objects carry labels and annotations identifying the policy and rule that produced them, so you can list the downstream fleet and count it. Do the counting in a test cluster too: the honest senior answer is that lifecycle behaviour under deletion is the part of any policy engine most worth verifying by experiment rather than by memory, because the cost of being wrong is measured in namespaces. ## The shape of the answer Name the coupling (synchronized downstream is owned, not copied), name the field that breaks it (`orphanDownstreamOnPolicyDelete`), name the direction of failure (fail-open, and silent, because nothing was denied), and name the compensating control (an independent validate rule or report, plus RBAC on the policy itself).