Description:
The hive-controllers pod running in the hive namespace is responsible for
reconciling the custom resources for Hive. This pod bundles all controllers
for hive in a single binary and container.

The ClusterDeployment.hive.openshift.io/v1 resource can be created with the
spec.installed field set to true (regardless of the installation status)
and a positive timespan for the spec.hibernateAfter value. If a
ClusterSync.hiveinternal.openshift.io/v1alpha1 resource is also created,
the hive hibernation controller will enter the reconciliation loop and
panic shortly thereafter, when accessing a non-existing field in the
ClusterDeployment’s status section.

This Denial of Service is persistent: the problematic resources are picked
up for reconciliation when the pod starts. This crashes it, then the
scheduling logic restarts it. The resource faulty resource has to be
manually removed for the system to restore itself.

Note that the testing environment co-locates hive components to a single
cluster. It is therefore not clear whether the observed behavior is
plausible in a standard setting.

Impact:
By leveraging F-02 Bypass in Managed Resources Admission Webhook, a user
with developer privileges can cause the hive hibernation controller to
panic in a loop, causing the pod to be put in the CrashLoopBackOff state.
The hive hibernation controller is bundled in the hive controller,
rendering all other bundled controllers unavailable.
Recommendations

If this finding is applicable under normal deployment and resource creation
conditions, check if the fields used by the controller on user-controlled
objects are present before accessing them.