Research if controller is able to detect and fix changes between the webhook object and its related ClusterAdmissionPolicy/AdmissionPolicy configuration.

[jvanz]

Verify if the Kubewarden controller is able to detect divergences between the webhook objects and the ClusterAdmissionPolicy/AdmissionPolicy configuration. If so, try to make the controller able to restore the webhook to the expected state. This issue trys to help mitigate the threat #4

NOTE: This is an issue created from RFC discussing the admission control threat model. It's created to allow the Kubewarden team discuss the proposed mitigation further and start to work on each actionable item when possible

[flavio]

We want the (Validating|Mutating)WebhookConfiguration object associated to a (Cluster)|AdmissionPolicy to be like our controller originally created it.

If a user changes these low level configuration objects, the controller should revert these changes.

[viccuad]

Reopening, the feature was reverted from kubewarden-controller @main with #569.

The current approach was to set OwnerReferences on the webhooks and watch them, for the controller to retrigger the reconcile of policies, eventually reconciling the webhooks too.

One cannot set an OwnerReference on a dependent across namespaces, or in our case, an OwnerReference on a cluster-wide dependant resource where the owner is a namespace. See here. If the GC would allow this, it would need for info to leak between namespaces, to allow for resources in one namespace to block deletion of resources in another one, would need to check for racing conditions, etc.