In Istio’s ambient mode, there’s a problem where pods that are marked for mesh can sometimes start running on a node before the Istio CNI plugin is fully set up. This race condition usually happens when a node restarts or when new nodes are added. If this happens, the CNI rules that redirect traffic don’t get applied to those pods. That means the mesh security policies aren’t enforced until the CNI comes up and the pods are restarted. During this time, the pods can run outside the mesh controls without anyone noticing, which is a security risk.

To reduce this issue, the Istio community added something called “Istio owned CNI config.” It basically makes a copy of the main CNI config, adds the istio-cni plugin, and then writes out a new config file with higher priority. This helps avoid the race condition, but it’s more of a temporary workaround. The long-term fix is expected to come from upstream CNI changes see  https://github.com/containernetworking/cni/pull/1052

Related PRs/Issues:

• https://github.com/istio/istio.io/pull/16749
• https://github.com/containernetworking/cni/pull/1052
• https://github.com/istio/istio/pull/56156
• https://github.com/istio/istio/issues/55968

Acceptance Criteria:

• Understand how easy it is to run into this kind of problems on an OpenShift cluster.
• Check and document whether the stopgap solution works on OpenShift clusters that use Multus CNI. The Istio-owned CNI config tries to set a higher priority, but Multus usually enforces itself as the first CNI to load. If Multus overwrites higher priority configs or strictly enforces this order, the Istio solution may not work.
• Identify if there is an easy way to figure out the list of pods where traffic is being bypassed and needs restart when we run into such an issue.