How to avoid that the default ingresscontroller serves routes of all projects when using router sharding in OpenShift 4.x

Solution Verified - Updated -


When configuring router sharing according to the documentation [0], it may be desired to serve specific namespaces only by specific ingress controllers. However, with the default configuration, the default ingress operator will still serve all services due to an absence of namespaceSelector or routeSelector configuration for this operator. Additionally, in environments which use hostNetwork for the ingress operators, such as vSphere, it is not possible to use network policies to block traffic from those operators due to [1].

For example, in an environment where is hosted by the default ingress controller and by the test1 ingress controller:

[stack@undercloud-0 openshift]$  curl
Apache default
[stack@undercloud-0 openshift]$ curl
Apache test1
[stack@undercloud-0 openshift]$ getent hosts | awk '{print $1}'
[stack@undercloud-0 openshift]$ getent hosts | awk '{print $1}'

In the above environment, an attacker could take advantage of this by changing the resolver and point it to the IP of the default ingress controller, using IP (the default namespace's ingress controller):

[stack@undercloud-0 openshift]$ curl -I --resolve 2>/dev/null  | grep HTTP
HTTP/1.1 200 OK
[stack@undercloud-0 openshift]$ curl --resolve 2>/dev/null 
Apache test1

How can one avoid that the default ingress controller serves routes of all projects when using router sharding in OpenShift 4.x?

Network policy does not apply to the host network namespace. Pods with host networking enabled are unaffected by NetworkPolicy object rules.


  • Red Hat OpenShift Container Platform 4.x

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.

Current Customers and Partners

Log in for full access

Log In

New to Red Hat?

Learn more about Red Hat subscriptions

Using a Red Hat product through a public cloud?

How to access this content