fix(kyverno): vendored Kyverno 1.17.2 requires MutatingAdmissionPolicy API absent on OpenShift 4.19/4.20 #166

Summary

The vendored Kyverno chart (charts/vendor/kyverno, chart 3.7.2, appVersion v1.17.2) cannot run on OpenShift 4.19 (Kubernetes 1.32) or 4.20 (Kubernetes 1.33).

Its admission controller unconditionally watches the admissionregistration.k8s.io/v1alpha1 MutatingAdmissionPolicy and MutatingAdmissionPolicyBinding APIs. Those APIs are not served on OpenShift 4.19/4.20, so the controller enters CrashLoopBackOff:

failed to list *v1alpha1.MutatingAdmissionPolicy: the server could not find the requested resource
failed to list *v1alpha1.MutatingAdmissionPolicyBinding: the server could not find the requested resource
failed to wait for cache sync

Impact

kyverno is a sync-wave 0 application. Because it reports Degraded, the app-of-apps health gate never releases waves 10/15/20/30 — so the pattern cannot converge at all on 4.19 or 4.20. This effectively sets the pattern's support floor at 4.21 for any deployment that uses sync-wave gating.

Reproduction

1. Install OpenShift 4.19.x or 4.20.x (any topology; observed on SNO).
2. Confirm the API is absent:

   oc api-resources | grep -i mutatingadmissionpolic   # no output

3. Deploy the pattern (with gitops.applicationHealthCheckEnabled: "true" so waves are gated).
4. Observe:

   oc get pods -n kyverno            # admission-controller CrashLoopBackOff
   oc logs -n kyverno deploy/kyverno-admission-controller   # errors above
   oc get applications.argoproj.io -n vp-gitops             # kyverno Degraded; only wave 0 exists

Environment

There is no configuration workaround

• features.generateMutatingAdmissionPolicy.enabled: false (already the default)
• features.mutatingAdmissionPolicyReports.enabled: false (already the default)

The informer is still registered, so disabling the feature flags does not help.

The vendored chart declares kubeVersion: '>=1.25.0-0', which claims support for these clusters — so this is a Kyverno defect relative to its own declared support, not an OpenShift-version limitation.

Proposed resolution (any one)

1. Per-version Kyverno pin — select an older Kyverno (one that does not watch MutatingAdmissionPolicy) for OpenShift versions whose Kubernetes does not serve the alpha API, keyed off global.clusterVersion; add the pinned image to the airgap imageset.
2. Upstream Kyverno fix — gate the MutatingAdmissionPolicy/MutatingAdmissionPolicyBinding informers on API discovery (ServerResourcesForGroupVersion), which would make 4.19/4.20 work with no pin.
3. Document the floor — record that 4.21 is the minimum supported version until either of the above lands (done in docs/supported-openshift-versions.md, being added alongside this issue).

Evidence

• OCP 4.19.53: kyverno-admission-controller in CrashLoopBackOff, wave-0 app Degraded, pattern stalled at wave 0.
• OCP 4.20.45: cluster installs cleanly (34/34 cluster operators Available) but oc api-resources | grep -i mutatingadmissionpolic returns nothing — the same precondition.
• OCP 4.22 (Kubernetes 1.35): Kyverno runs and is Healthy; the pattern validates end-to-end (PR fix(airgap): mode-agnostic disconnected fixes and sync-wave gating #165).

Related

• Support matrix / floor documentation: docs/supported-openshift-versions.md
• PR fix(airgap): mode-agnostic disconnected fixes and sync-wave gating #165 — the sync-wave gating work that makes this a hard stop rather than a silent ordering race