3. What is the nature and description of the request? OpenShift allows to join project networks in "multi-tenant" mode: https://docs.openshift.com/enterprise/latest/admin_guide/pod_network.html The command line gives the impression that this is a "directed" join (due to the "to" parameter): oadm pod-network join-projects --to=<project1> <project2> <project3> However, Joined projects can join each others services in all directions, and not just from <project2> to <project1>. We would like to raise a feature request so that we can directionally join project networks. Source projects shall be able to access services in a "target" project, but the target project shall not be able to access services in the source projects, nor should a variety of source projects be able to communicate with each other. 4. Why does the customer need this? (List the business requirements here) The customer would like to run certain services in a centralized fashion, and provide these services to a sub-set of projects (but not to all projects). The "global project" approach of OpenShift therefore is not fitting. Some concrete use cases are: - centrally managed HTTP forward proxy (but different instances for different subsets of projects) which could be access from multiple projects while these projects remain segregated. - centrally managed Jenkins (but different instances for different subsets of projects) where Jenkins could access some development projects, but the various projects would remain isolated from each other. One driving aspect for identifying sub-set of projects is the customers network segmentation model, where some projects (with the same criticality and same customer entity) are allowed to share services, and other projects need to consume dedicated additional instances of centralized services. Other reasons to group sub-sets of projects could be envisaged. 5. How would the customer like to achieve this? (List the functional requirements here) by making oadm pod-network join-projects --to=<target> <source> --directed=true directional. This command would only allow access from source to target, and not the other way. 6. For each functional requirement listed in question, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. - Perform oadm pod-network join-projects --to=<target> <source> --directed=true - deploy a pod in each project with a http service each - wget from target to source --> fail - wget from source to target --> succeed. 7. Is there already an existing RFE upstream or in Red Hat bugzilla? Not that the customer would be aware. 8. Does the customer have any specific timeline dependencies? A 3.5 timeframe would be great. Right now, the customer is deploying potentially shareable "proxies" in each project. By that time, the customer will have enough volume that sharing such a service would make sense.
We are working on implementing the Kubernetes NetworkPolicy object. Right now we expect that work to be ready by 3.5. You can track the Epic in https://trello.com/c/p9rMmf4K/305-epic-implement-upstream-networkpolicy
Here are some docs on it: https://kubernetes.io/docs/concepts/services-networking/network-policies/
From looking at the epic I see all the attached stories were committed-3.6. I'm marking this ON_QA in case QE wants to make one last sanity check with the official build.
The networkpolicy plugin has been implemented in 3.6, and the feature works well in the latest build v3.6.173.0.2
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:1716