Add CNI support when iptables are unavailable (e.g. OpenShift4)

[jshaughn]

I've tried installing OSM 0.3 on OpenShift 4.5 and was able to get the control plane pods running. But the bookstore app pods will not start because the init-container requires iptables which are not used in OpenShift. The same issue was solved in Istio via CNI support (see this Istio issue for more).

OpenShift users will be blocked without CNI support or some sort of ecure workaround I'm not aware of.

Scope (please mark with X where applicable)

• New Functionality [ x]
• Install [ x]
• SMI Traffic Access Policy [ ]
• SMI Traffic Specs Policy [ ]
• SMI Traffic Split Policy [ ]
• Permissive Traffic Policy [ ]
• Ingress [ ]
• Egress [ ]
• Envoy Control Plane [ ]
• CLI Tool [ ]
• Metrics [ ]
• Certificate Management [ ]
• Sidecar Injection [x]
• Logging [ ]
• Debugging [ ]
• Tests [ ]
• CI System [ ]
• Project Release [ ]

[michelleN]

@ksubrmnn - What are your thoughts around this? Could you help us scope this work to see what all would be involved to support OpenShift?

[davinci26]

As part of Windows Support for OSM #2082 we could use a CNI plugin.

The existing alternative (init_container) is not possible on Windows since modifying HNS policies requires the container to modify host properties as an administrator. Which leaves us with the CNI as the best way forward.

This would require some further research to address the following questions:

CNI plugin specific question

1. How is the CNI plugin deployed on the cluster? We should consider the case of a fresh cluster and also the case where we install OSM into an existing cluster.
2. How are binaries distributed?

CNI plugin api

How does the CNI plugin communication with OSM?

I think these are only the preliminary questions and the next step is to submit a detailed RFC to answer to these and solicit feedback from the community.

[plwhite]

I'm definitely interested in this option. For the record, the Istio answers to the above are:

• The installation gives the option of using a DaemonSet, which appends the Istio CNI to the end of the chain.
• The binaries are distributed by the DaemonSet, but where they ultimately come from I haven't investigated. I can believe there needs to be some configuration of CNI binary version etc., including the ability to download it from a local source (for offline operation).
• The CNI plugin just reads the annotations from the pod, and uses those to discover what to do; in particular it reads whether the mesh is enabled, what ports are applicable etc..

Some customers have security policies that might mandate this approach (they will not accept an init container with the required network privileges). The DaemonSet approach for distribution seems almost as bad as the init container privileges question to me from a security point of view, but I'm not a security expert.

[github-actions]

Added default label size/needed. Please consider re-labeling this issue appropriately.

[github-actions]

Added default label kind/needed. Please consider re-labeling this issue appropriately.

[github-actions]

This issue will be closed due to a long period of inactivity. If you would like this issue to remain open then please comment or update.

[github-actions]

Issue closed due to inactivity.