When servicing a webhook configured via the aggregated APIServer mechanism, the kube apiserver (KAS) has special case to ignore the caBundle in the *webhookconfiguration and authenticate the request transparently. Thus, for hive's webhooks to function correctly, our injection of the caBundle via either of the two mechanisms below was superfluous.

• For OpenShift clusters, we were using the service.beta.openshift.io/inject-cabundle: "true" annotation. It turns out this was incorrect to begin with, as it injects the wrong bundle!
• For non-OpenShift clusters, we were discovering the KAS's cert by looking for a(ny) Secret of type kubernetes.io/service-account-token. Starting with k8s 1.24, such Secrets are no longer generated automatically, so we were laying down our own to be populated.

However, there's an openshift component, the kube-apiserver-operator (hereinafter KASO) which attempts to validate webhook configurations, and at the time of this writing it does not have that special case; so, without the correct caBundle configured, that validation fails, resulting in harmless but ugly log entries.

OCPBUGS-50978 has more details on this issue, and is also tracking the KASO change to add that special case so the two components behave the same way. With this card we'll rework the hive side to make sure the correct caBundle exists in our webhook configs so that older versions of OCP will also stop throwing that error in the KASO logs.