Section Number and Name:
Configuring Clusters - Configuring the SDN - Migrating Between SDN Plug-ins - Migrating from ovs-multitenant to ovs-networkpolicy
Describe the issue:
Need elaboration on the security hardening pertaining to NetworkPolicy SDN plugin. The referenced case 02264638 is an example where the customer wanted clarity on security hardening over NetworkPolicy SDN plugin.
Suggestions for improvement:
We can add a note in documentation conveying that for the default Openshift projects, we require the pods to communicate with other pods from other projects and vice versa. Hence, user should not indulge in the default functionality for the pods in default project. In order to have such default networkpolicies set for Openshift projects (default, openshift-sdn etc.), we would require Egress functionality as well which is not available yet and it all needs to be tested by Engineering first.
While for the user created projects, the end user can manage the networkpolicies separately.
The main concern of customer is security hardening for default Openshift projects. This is where they intended to create custom networkpolicies to control traffic between application projects and default Openshift projects. Currently, they should not be dealing with it as it might affect the cluster adversely.
Thank you for bringing this bug to our attention. I have found a note in other parts of our documentation that describe what Ravi was requesting:
"Only the v1 NetworkPolicy features are available in OpenShift Container Platform. This means that egress policy types, IPBlock, and combining podSelector and namespaceSelector are not available in OpenShift Container Platform."
I will add this to 3.6+ with QA's approval. Bo Meng, Please take a look at the PR:
The change looks good to me.
Please help check if it could be verified.
Changes are merged.
Changes have been merged to 3.7+ . I originally was planning to cherrypick to 3.6, however it seems NetworkPolicy was tech preview for that release. Setting release pending.
These changes are now live in 3.7+ . As this bug was filed against 3.10 I've provided the URL below:
I will now file this bug as closed/current release.