Re: [che-dev] Single Host Option

[Lukas Krejci <lkrejci@xxxxxxxxxx>]

Let me summarize my view on the single host deployment model and the pros and 
cons associated with it.

First, let me quickly describe what is meant by single-host so that we are all 
on the same page (not that it may not be completely true to the way we deploy 
stuff today, but it depicts the idealized state).

https://che-host -- the root URL and the one a TLS certificate is issued for
                /keycloak -- web root of keycloak deployment
                /dashboard
                /api
                /asnfjalw -- random names for exposing servers in workspaces

== First, the security considerations:

- any cookie set for che-host is readable by all subpaths - we therefore need
to be very careful to not expose any sensitive information like JWT tokens 
through cookies on paths too "broad". Note that today, we already take care of 
JWT cookies for individual workspace components in single-host mode by making 
sure they are set only for appropriate subpaths and therefore don't leak to 
other components (i.e. we're making sure cross-workspace auth stealing is not 
possible).

- There is also a problem with local storage in the browser. Unlike cookies, 
which are domain AND path based, local storage is only domain-based and so any 
local storage data is readable by code originating in any subpath. Translated 
into our usecase, Theia plugins will be able to read any data stored in the 
browser local storage from ANY WORKSPACE. This becomes a potential security 
risk in a situation where a single browser is used by more than 1 user, which, 
frankly, is not that common. This becomes a security risk also if we consider 
Theia plugins as not trusted.

- Futher, separating webviews by domain makes inter-frame communication more 
secure. If everything originates on a single domain, Theia and its plugins can 
potentially step on each others' toes.

- TLS everywhere - since everything in this scenario is using a single host, 
it is impossible for the applications in workspaces to NOT use TLS or use a 
different certificate.

- More problems are possible with webviews - I don't know webviews as much and 
am looking forward to getting to know more from the experts.

== Second, deployment considerations:

- I think we need to be prepared to not only deploy everything on single host 
but also offer the option to e.g. deploy keycloak on a separate, user-defined, 
domain with a custom certificate - just to enable security separation.

- server-side generated links will be even harder for user applications in 
workspaces. Even today, there is the "divide" between what host name the app 
is seen from outside of the cluster vs what host name it is using inside of 
the cluster. Hence, even today, if the user application generates on the 
serverside an absolute link including a hostname, it will not be reachable 
from outside of the cluster. But that is nothing unusual - people are used to 
the concept of NAT and there techniques to overcome this - namely just don't 
use hostnames in the server-side generated links. The situation becomes worse 
with single-host though, because not only the hostname becomes different, but 
also the path. Many cloud native apps assume to be deployed in the web root 
'/' which is not going to be the case in single-host. Therefore, if the app 
generates on the serverside a link to itself without a hostname, like for 
example '/checkout' (notice that it doesn't contain the hostname), such link 
will not work outside of the cluster, because there that link should have 
looked something like '/aswkjnclkasrs/checkout' (where the random part is 
generated by Che to provide component segregation). Also, today, the random 
part of the path changes on each workspace restart, making it even more 
difficult to accommodate (partially solvable by exposing the random path in an 
environment variable for example).

- Here again, we need to take webviews, local storage and inter-frame comms 
into consideration.

== Way forward

IMHO, enabling single-host is going to invariably weaken the security of Che 
and workspace deployments but it can be an informed trade-off that might work 
for some users. The user needs to know that they give up some security in the 
Theia IDE which can be somewhat mitigated by using a controlled plugin 
registry and somehow disallowing using plugins from outside of it (we don't 
have that capability atm).

The problems with user apps not expecting being behind a path-rewriting 
reverse-proxy are more difficult to deal with. We could just accept that as a 
drawback of single-host mode.

If we potentially offered an option to deploy parts of the workspace on 
separate domains, we would most probably deploy plugins and editors honoring 
the single-host mode and only deploy dockerimage and k8s/os components using 
separate domains. The terminals in the UI would still work because they are 
facilitated through che-machine-exec, it's only the applications started in 
the containers that would need to be exposed through dynamically created 
ingresses/routes. These would either still need to be handled through a 
wildcard certificate or just given exceptions in the user's browser.

Note though that by the above we would not solve the "too many routes per 
workspace" issue that we also want to address. This is because the fact that 
to be able to access individual components of workspaces we need path 
rewriting ingresses that translate the requests on per-component basis. To 
solve the "too many routes" problem, we would have to basically implement our 
own dynamically reconfigurable reverse-proxy that would be able to do that 
path rewriting without opening another ingress. Basically we would have to 
copy the functionality of the nginx-ingress-controller only not handling 
ingress objects but our own equivalent.

I wrote all of this just to point out a few things we need to consider and 
also draw our collective attention to the fact that this is not going to be a 
simple undertaking.

Thanks,

Lukas

On Monday, April 20, 2020 1:40:29 PM CEST Mario Loriedo wrote:
> Hi all,
> 
> We currently support single-host option as a workspaces exposure strategy
> <https://www.eclipse.org/che/docs/che-7/configuring-workspace-exposure-strat
> egies/> [1]
> (on Kubernetes only):
> 
> In short the difference is that in single-host mode mode URLs look like:
> 
>    https://example.com/app
> 
> whereas in multi-host (currently the default one) URLs look like:
> 
>    https://app.example.com/
> 
> 
> The single-host strategy has a couple of important benefits when running
> Che on TLS:
> - No need for wildcard certificates (*.example.com)
> - No need to manually import self signed certs
> <https://www.eclipse.org/che/docs/che-7/installing-che-in-tls-mode-with-self
> -signed-certificates/#using-che-with-tls_installing-che-in-tls-mode-with-sel
> f-signed-certificates>
> 
> Considered the benefits that looks like single-host should be the default
> right? Well that's what I would like to start consider but we should
> carefully evaluate the drawbacks.
> 
> A first drawback has been mentioned by platform team last week and that's
> related to Theia security. Do we have more info about this?
> 
> Another drawback is about users applications: in some cases they won't work
> out of the box as mentioned in the doc
> <https://www.eclipse.org/che/docs/che-7/configuring-workspace-exposure-strat
> egies/#single-host-strategy>. But that's something that we may document and
> even fix making users apps ingresses "multi-host" by default and let users
> deal with the certs.
> 
> Mario
> 
> [1]
> https://www.eclipse.org/che/docs/che-7/configuring-workspace-exposure-strate
> gies/ [2]
> https://www.eclipse.org/che/docs/che-7/installing-che-in-tls-mode-with-self-> signed-certificates/#using-che-with-tls_installing-che-in-tls-mode-with-self
> -signed-certificates [3]
> https://www.eclipse.org/che/docs/che-7/configuring-workspace-exposure-strate
> gies/#single-host-strategy