Bug 1374674

Summary: Directional joining of multitenant network
Product: OpenShift Container Platform Reporter: Jaspreet Kaur <jkaur>
Component: RFEAssignee: Ben Bennett <bbennett>
Status: CLOSED ERRATA QA Contact: Meng Bo <bmeng>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.2.0CC: aos-bugs, bbennett, bleanhar, bmeng, bparry, erich, javier.ramirez, jokerman, mmccomas, simon.gunzenreiner, sjr
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-10 05:15:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jaspreet Kaur 2016-09-09 11:52:45 UTC
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.

Comment 2 Ben Bennett 2016-09-09 13:13:40 UTC
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

Comment 8 Ben Bennett 2017-07-26 11:04:52 UTC
Here are some docs on it: https://kubernetes.io/docs/concepts/services-networking/network-policies/

Comment 9 Brenton Leanhardt 2017-08-01 12:26:49 UTC
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.

Comment 10 Meng Bo 2017-08-02 10:31:19 UTC
The networkpolicy plugin has been implemented in 3.6, and the feature works well in the latest build v3.6.173.0.2

Comment 12 errata-xmlrpc 2017-08-10 05:15:47 UTC
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