Operators shipping with network policies may require OCP cluster upgrade before they can be upgraded

Updated

In order to comply with OpenShift Hardening requirements, each Operator from Red Hat is required to ship with Network Policies, beginning February 2027. Operator Lifecycle Manager (OLM) had to be updated as well across all the supported versions of OpenShift to enable operators to include Network Policies.

This change requires the OpenShift cluster to be upgraded to a compatible z-stream version first, before operator updates shipping NetworkPolicy manifests in their resource bundle can be conducted. This applies to all currently available versions of OCP, including OCP 4.12 and 4.14.

This means that if you are trying to update an operator that ships a NetworkPolicy definition and the OCP cluster version is below the relevant z-stream version that supports Network Policies in OLM-managed operators, the operator update will fail and will require manual recovery. The list of OCP versions that support Network Policies in OLMv0 and OLMv1 is below.

List of minimum OCP versions required to support Network Policies in OLM:

OpenShift versions
4.20.0 or newer
4.19.10 or newer
4.18.23 or newer
4.17.39 or newer
4.16.48 or newer
4.15.58 or newer
4.14.57 or newer
4.13.61 or newer
4.12.81 or newer

You may see the following `InsightsRecommendationActive` info severity alert firing in your cluster related to this issue, which recommends the cluster upgrade:
Insights recommendation "OLM operator installations and upgrades fail when the current OCP cluster version is too old" with total risk "Moderate" was detected on the cluster. More information is available at https://console.redhat.com/openshift/insights/advisor/clusters/<cluster id>?first=ccx_rules_ocp.external.rules.cluster_does_not_support_olm_operators_network_policies%7COCP_DOES_NOT_SUPPORT_OLM_OPERATORS_NETWORK_POLICIES.

If you experience failed updates of operators attempting to ship NetworkPolicy definitions due to running an earlier OCP version than one of the ones listed above, please review This content is not included.KCS 7134250 for remediation steps/instructions.

Scenario 1: OCP version is below the recommendation but no operator update shipped NetworkPolicy definitions yet

For unpatched clusters, where a failed update is due to an invalid InstallPlan containing NetworkPolicy has not yet occurred, plan to upgrade your cluster at least to the minimum patch level listed in the table above.

Pre-cluster update: Disable auto-updates for installed operators by setting all OLM Subscriptions to Manual approval mode, do not approve any install plans containing NetworkPolicy until you've updated to a patched OCP version listed above.

You can run the following command to determine if there are pending InstallPlan instances waiting for approval to conduct an update that contains NetworkPolicy manifests:

# oc get installplan -A -o go-template='
NAMESPACE   NAME           CSV(s)                        FAILING-RESOURCE
---------   ----           ------                        ----------------
{{- range .items }}
  {{- if eq .status.phase "RequiresApproval" }}
    {{- $ip := . }}
    {{- $ns := .metadata.namespace }}
    {{- $name := .metadata.name }}
    {{- $csvs := "" }}
    {{- range $i, $c := .spec.clusterServiceVersionNames }}
      {{- if gt $i 0 }}{{ $csvs = printf "%s,%s" $csvs $c }}{{ else }}{{ $csvs = $c }}{{ end }}
    {{- end }}

    {{- range .status.plan }}
      {{- if and (eq .resource.group "networking.k8s.io") (eq .resource.kind "NetworkPolicy") }}
{{ printf "%-11s %-14s %-29s %s/%s/%s\n" $ns $name $csvs .resource.group .resource.kind .resource.name }}
      {{- end }}
    {{- end }}
  {{- end }}
{{- end }}
'

NAMESPACE   NAME           CSV(s)                        FAILING-RESOURCE
---------   ----           ------                        ----------------
example     install-8bp2p  example-operator.v1.1.0       networking.k8s.io/NetworkPolicy/example-operator-networkpolicy

- OR -

Pre-cluster update: Disable updates for operator catalogs by disabling the default CatalogSources via the OperatorHub API, re-apply the same CatalogSources using a fixed catalog digest to avoid pulling updated catalogs that contain NetworkPolicy in their bundles until you've updated to a patched OCP version listed below. This will prevent the cluster from receiving/applying any operator updates from these catalogs.

Post-cluster update:

  1. Approve any pending InstallPlans, which should now succeed
  2. Delete custom CatalogSources created from the previous step (if any) and re-enable the default catalogs via the OperatorHub API.

Scenario 2: OCP version is below the recommendation and an operator update shipping NetworkPolicy definitions failed

Please review This content is not included.KCS 7134250 for remediation steps/instructions to clean up the failed update. Afterwards, plan to upgrade your cluster at least to the minimum patch level listed in the table above. Then reapply the updates.

Scenario 3: OCP version is below the recommendation and you cannot upgrade yet

Set all OLM Subscriptions to Manual approval, do not approve any install plans containing NetworkPolicy until you've updated to a patched OCP version listed below

- OR -

Disable default CatalogSources via the operatorhub API, re-apply CatalogSources using a fixed catalog digest to avoid pulling updated catalogs that contain NetworkPolicy in their bundles until you've updated to a patched OCP version listed below. This will prevent the cluster from receiving/applying any operator updates from these catalogs.

Category
Components
Tags
Article Type