Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1749844

Summary:	Need a way to allow ingress from hostsubnet pods in netpol
Product:	OpenShift Container Platform	Reporter:	Juan Luis de Sousa-Valadas <jdesousa>
Component:	Networking	Assignee:	Dan Mace <dmace>
Networking sub component:	router	QA Contact:	Hongan Li <hongli>
Status:	CLOSED DUPLICATE	Docs Contact:
Severity:	low
Priority:	unspecified	CC:	aos-bugs, danw, pbertera
Version:	4.1.z
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-11-28 14:49:32 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 Juan Luis de Sousa-Valadas 2019-09-06 14:51:51 UTC

Description of problem:
Customer needs to allow pods with hostNetwork: true to connect to pods with networkPolicy restrictions.

In OCP 3.x this could be achieved by allowing the default net namespace which had vnid: 0 by default, so it would create an entry allowing traffic where reg0=0

Version-Release number of selected component (if applicable):
4.1.X

How reproducible:
Always

Steps to Reproduce:
1. Create a pod with hostNetwork in namespace X
2. Create a pod in namespace Y allowing only traffic from namespace X
3. Try to connect from pod in namespace X to pod in namespace Y. Won't work unless both pods are on the same node

Actual results:
- 

Expected results:
-

Workaround:
1. create a project hn-workaround
2- oc get netnamespace hn-workaround -o yaml | sed 's/netid:.*/netid: 0' | oc replace -f-
Patches don't seem to work, I haven't bothered enough to investigate why, but oc replace works fine
3- restart every sdn pod (I also tried creating the netnamespace before the projcut but either way seems to need a restart, again, I haven't bothered to understand why).

Comment 1 Casey Callendrello 2019-09-09 12:52:28 UTC

This is a pretty fundamental limitation of how k8s network policy works - you generally can't grant access to host network pods, because they generally don't source traffic from their PodIP.

It's interesting to see that this worked in 3.x. In other words, that *all* hosts could access *all* endpoints. I'm not sure if this is as expected.

Then again, perhaps it's a reasonable expansion. We already say that a host can access all of the pods running on that host.

Dan, thoughts?

Comment 2 Dan Winship 2019-09-10 12:34:35 UTC

NetworkPolicy-vs-hostNetwork worked exactly the same in 3.x as it does in 4.x.

The original problem, from the support case is:

> After creating an allow-from-openshift-ingress network policy object, the
> openshift router can't access the pod anymore. It seems that traffic coming
> from the openshift-ingress namespace is not considered coming from the
> openshift-ingress namespace but from the openshift node itself because the
> router uses the host network.

Routers are not hostNetwork by default in 4.1. This is an alternate mode. Our documented instructions for making routers work assume that you're not using that mode. So we should fix that.

After that, from what I can see, the customer reported that they had allowed traffic from VNID 0 and that *did* fix the problem for them (and then they closed the case).

Comment 3 Casey Callendrello 2019-10-24 08:13:11 UTC

Perhaps we should also label the default namespace with something like "network.openshift.io/policy-group: host-network"

Comment 5 Juan Luis de Sousa-Valadas 2019-11-28 14:49:32 UTC


*** This bug has been marked as a duplicate of bug 1768608 ***