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.
It looks like bypassing the reverse proxy for user applications makes UX
much much simpler.
And I feel like developers can live with http routes for their applications (no need
for wildcard certificates). And that admins can live with one route per user
application (this is an important improvement of current 5 workspaces routes plus
applications routes).
I think we should default to no proxy per user applications.
But it all depends on what kind of restrictions are we willing to impose on
the users running the single-host mode.
Thanks,
Lukas
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev
