We should use services hostname instead of ingresses for inter-components communications

[l0rd]

Is your enhancement related to a problem? Please describe.

When wsmaster try to reach Keycloak it uses its external ingress/route hostname instead of using the internal service hostname. That makes sense only if Keycloak is external (the exception).

This is a problem because HTTP requests may need to follow a complicated and venturesome path going through proxies, firewalls etc...

This is NOT a wsmaster <--> keycloack specific problem. The plugin broker has the same issue when communicating with the registries and the wsmaster. And other Che components may have the same problem.

Describe the solution you'd like

All communications between Che services, by default, should use the cluster internal service hostname.

[sleshchenko]

All communications between Che services, by default, should use the cluster internal service hostname.

I think it worths to declare that different communication should be configurable like Che and Keycloak are run in the same namespace and there is no reason to use external networking except external keycloak is used ( as is described in the issue ).
But Plugin Broker - Che Server communication should be configured according to cluster network policies, since those components are run in a different namespace and usually ( I think ) Che Server is not available for Plugin Broker via service hostname (internal network).

[l0rd]

Che Server communication should be configured according to cluster network policies, since those components are run in a different namespace and usually ( I think ) Che Server is not available for Plugin Broker via service hostname (internal network).

@sleshchenko you are probably referring to the OpenShift Online cluster (che.osio) network policy that blocks communications across namespaces. That's a cluster with a peculiar configuration. By default communications across namespaces are enabled on both Kubernetes and OpenShift.

[AndrienkoAleksandr]

Hello. @l0rd , @sleshchenko we are going to introduce cheCluster settings to enable internal network. Let's call it useInternalNetwork and it will be disabled by default. I think it will be safe way to start playing with this stuff.

[ibuziuk]

Not sure if this is relevant but in order to achive the network isolation on 3.11 the multitenant sdn
plugin is used https://docs.openshift.com/container-platform/3.11/architecture/networking/sdn.html which enables multi-tenant mode.

for 4.x clusters network policy is used to achieve multitenancy - https://docs.openshift.com/container-platform/4.1/networking/configuring-networkpolicy.html#nw-networkpolicy-multitenant-isolation_configuring-networkpolicy-plugin

By default, all Pods in a project are accessible from other Pods and network endpoints. To isolate one or more Pods in a project, you can create NetworkPolicy objects in that project to indicate the allowed incoming connections. Project administrators can create and delete NetworkPolicy objects within their own project.