Impact statement for the OCPBUGS-43454 series:

Which 4.y.z to 4.y'.z' updates increase vulnerability?

Customer using secondary OVN-Kubernetes networks of localnet topology without subnets upgrading from any 4.16 to any 4.17.

This is pretty much any virtualization customer using localnet secondary networks - since networks with subnets defined are not supported for virt workloads.

Cluster assessment

Read all network-attachment-definitions (which is a Kubernetes CRD) of a cluster:

oc get network-attachment-definitions.k8s.cni.cncf.io --all-namespaces

If there are no instances, the cluster should not be exposed. Otherwise, check every instance:

oc get network-attachment-definitions.k8s.cni.cncf.io --namespace $N $NAME -o 'jsonpath={.spec.config}' | jq '{type,topology,subnets}'

If at least one instance matches all following criteria, the cluster is exposed to the risk during update, and it is recommended to update it only to a version where OCPBUGS-43454 is fixed (4.17.7 and above):

• type is ovn-k8s-cni-overlay
• topology is localnet
• subnets is omitted, or empty

Which types of clusters?

All of them.

What is the impact? Is it serious enough to warrant removing update recommendations?

The upgrade will not finish successfully; newly added workloads will not be able to be created.

How involved is remediation?

Admin must remove all the workloads attached to all their localnet networks (without subnets), then remove all their localnet networks without subnets. Meaning, all the localnet topology networks in use for virtualization users must be removed, alongside the VMs connected to them.

is a regression?

Yes; introduced in 4.17.0 .