[che-dev] How invisible to make the single host gateway?

[Lukas Krejci <lkrejci@xxxxxxxxxx>]

Hi all,

We've come back to the issue of the single-host support on OpenShift and it is 
becoming clear that this is not going to be a completely seamless thing. I 
invite you to read through the lengthy descriptions below and think about what 
you would/would not like as a Che user or Che administrator and how would you 
envision solving the outlined problems.

tl;dr

We need to decide whether:

1) Cookie path rewriting is required in workspaces and plugins
2) Location header path rewriting is required in workspaces and plugins
3) Whether it is OK to run workspaces in their own subdomains even in single 
host mode.

Now for the detailed discussion of the points above:

First, there is the issue of the 2 purposes we're trying to use this for:
a) Exposing plugins and editors
b) Exposing applications running in workspaces

While we can easily say "the plugins and editors need to follow these rules", 
we can't really do that for workspace applications. We want to impose as 
little on them as possible.

Now the single host mode ALREADY does impose one big restriction on the 
workspace applications - they cannot use server-side-generated 
absolute URLs without consideration, because the host and path they see is 
just different from what they're seen as from the outside of the cluster. For 
the URLs to work, the application needs to support some kind of configuration 
that can tell it the webroot for generating the absolute URLs.

Now for the other issues we found during our experimentations with different 
API gateways. Generally it boils down to the difficulties configuring the path 
rewrites in all places required:

1) Cookies with paths - if the user application defines a cookie on a sub-
path, this sub-path needs to be translated to the outside visible 
representation. We know that HAProxy and Nginx can be configured to do this, 
Traefik doesn't support it and we weren't yet able to find Envoy configuration 
for this. This can be seen as a slight security problem though, because it can 
enable overwriting cookies that don't belong to the application. Cookies are 
generally known to not be secure so this is a no big issue but IMHO we should 
not make the situation more complex for the users if possible.

2) Redirects - HTTP status code 301 requires the Location header to contain 
the location to which to redirect to. So far, we were able to only configure 
Nginx to correctly rewrite this header such that the redirect doesn't "escape" 
the workspace. On the other hand this might not even be a desired behavior 
because a) the redirect is free to point to another host altogether and b) it 
sometimes might be even desirable (2 user apps running in their respective 
workspaces).

Both of the above problem have a semi-standard solution - the gateways are 
able to submit the X-Forwarded-For header which can be taken into the account 
by the backend applications when composing the cookie and location paths.

This, on the other hand, is yet another rather heavy requirement on the 
applications running inside workspaces.

Now to the bullet point 3) - can this all be solved by just running the user 
applications on separate subdomains even in single-host mode?

IMHO, the answer is no because of the usability concerns. If the whole point 
of single-host mode is to reduce the number of routes and, more importantly, 
not require wildcard certificate for Che, we should not come up with a 
solution that still requires a potentially unbound number of both. We could 
try to for example expand on the already existing limit of the concurrently 
running workspaces and also introduce limits for the max number of routes per 
user (with the admin somehow supplying che with a set of certificates to be 
used with each such route), but IMHO that is a bit cumbersome solution.

But it all depends on what kind of restrictions are we willing to impose on 
the users running the single-host mode.

Thanks,

Lukas