Impact statement for the OCPBUGS-33500 series:

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

• all updates from 4.13.z to 4.14.z

Which types of clusters?

• all OVN clusters with IPsec enabled, which will have a ovnkube_master_ipsec_enabled metric, and the value of that metric will be 1.

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

After discussing this with pepalani@redhat.com , the impact of this bug is that during the first phase of the upgrade of ovn-kubernetes from 4.13 to 4.14, not all east-west traffic is encrypted, since the ipsec pods are not up. More specifically:

• traffic via geneve tunnels is still encrypted (e.g. two pods on different nodes); (pod-to-pod on the same node is never encrypted)
• pod-to-node traffic is not encrypted
• node-to-node traffic is not encrypted

How involved is remediation?

The issue resolves itself once cluster network operator moves ovnkube to the second and final phase of the upgrade. The duration of the first phase depends linearly on the number of worker nodes in the cluster; I expect the three master nodes to update sequentially in 5-6 minutes; I expect ovnkube-node to take typically 1-2 minutes for every set of worker nodes updating in parallel. The rolling update strategy we configured allows  maxUnavailable=10%, so 10% of worker nodes are updating in parallel at any given time.

Is this a regression?

No, it has always been like this we just never noticed.