This is useful Lukas. Thank you for the detailed explanation.
amongst plugins. A plugin will be able to access sensible data managed by
any of the workspaces of the user. I have added some comments inline.
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).
If I read correctly for cookies and same origin issues we should be already covered
- 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.
In short the message to the user is: don't add plugins that you do not trust because
they will get access to sensible data. I assume that's acceptable because VS Code
extensions running locally have access to (more) sensible data right? But we need
to explicit that clearly (to users, PMs and devs) because one of the point of using
Che is that is more secure than local development...
- 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.
If I am correct that translates again into "the message to the user is: don't add
plugins that you do not trust"
- 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.
TLS everywhere is good but I am just wondering why. I mean if in a workspace,
a user defines his runtime application endpoint to be **NOT** secured shouldn't
we create, that particular endpoint only, as a multi-host, no TLS, no path-rewrite
endpoint?
- 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.
Webview experts, please provide share your wisdom then!
== 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.
Yes that's what I was thinking as well. We may use an explicit field in devfile
endpoints like `avoidPathRewrite: true`.
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.
Right. Solving the "too many routes per workspace" Che side never convinced
me: a kubernetes cluster has already one or more reverse proxies. Deploying
and operating our own reverse proxy sounds wrong.
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
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev
