Simplify authentication and authorization with a more flexible and lightweight approach

[skabashnyuk]

Is your task related to a problem? Please describe.

We would like to revise the way how we do authentication and authorization in Eclipse Che.

Requirments

• Remove Keycalok dependency in general.
• On OpenShift, use OpenShift OAuth directly (do not require Keycloak or any OIDC provider)
• Every Che user should be authenticated as a Kubernetes user
• Do not deploy a component if we do not need it (OpenShift)
• Get rid of postgres for Keycloak
• Support any OIDC provider

Problems that we currently have with Keycloak:

• Users removal (that need to be done twice on OpenShift install)
• User registration (credentials are asked twice)
• kubeadmin is not a valid user

Describe the solution you'd like

Something like OAuth2 proxy looks like the ideal solution

• We would delegate authentication to a single component (reverse proxy) that would intercept every request and authenticate them
• It’s not OpenID, there is no guarantee to have user id and email
• There may be some issues with Traefik

Dex, rbac-proxy and OpenShift OAuth need to be evaluated as well

Implementation

• Create test application for authentication/authorization prototyping #19192
• Try to setup minikube + dex + OIDC + RBAC #19196
• [Che auth] - Openshift + oauth2-proxy #19229
• OAuth2 proxy+ traefik
• [Che auth] - setup kube-rbac-proxy with demo app #19297
• [che-auth] Setup full che-like auth flow on Kubernetes #19357
• [che-auth] Setup full che-like auth flow on Openshift #19358
• [che-auth] - oauth-proxy can't put token into Authorization header #19704
• [che-auth] - make it possible to deploy Che with new auth #19705
• [che-auth] - adapt che-dashboard to new authentication #19706
• [che-auth] chectl should not wait for keycloak in nativeUserMode #20009
• [che-auth] - use traefik plugin to set authorization header #20070
• [che-auth] - enable nativeUserMode by default on openshift with devworkspaces #20203
• [che-auth] It is not possible to logout in nativeUserMode #20071
• [che-auth] - secure workspace subpath endpoints in new auth gateway #19707
• [che-auth] secure workspace services #20190
• [che-auth] - subdomain (a.k.a. multi-host) routes auth #19550
• [che-auth] Chectl Setup Che7 with Dex instead of Keycaloak as OIDC provider for minikube #19366
• [che-auth] Che with Devworkspaces should be able to use Dex as identity provider on OIDC enabled k8s #20362
• [che-auth] che-server support for native auth on kubernetes #20633
• [che-auth] deploy with native authentication on Kubernetes #20635
• Dashboard backend support for native auth on kubernetes #20677
• [che-auth] document native user auth #20847

Additional context

• Multi cluster support #18617

[skabashnyuk]

@skabashnyuk
kube-rbac-proxy could help us. For example https://github.com/brancz/kube-rbac-proxy/tree/master/examples/oidc

@metlos according to @davidfestal kube-rbac-proxy does "almost but not quite" do what we need... But it certainly should be a good starting point

@davidfestal Yeah, I was mainly thinking of a mix of 1. kube-rbac-proxy and 2. oauth2-proxy.

2. for integrating the UI flow (to grab the user token to then check thanks 2
3. for TokenReview and using RBAC control
   cf:
   "The token is then used for token review by the Kubernetes API. This already works with the existing kube-rbac-proxy functionality. The resulting metadata (user and/or group information) is then passed to the subject review Kubernetes API for authorization."

in https://github.com/brancz/kube-rbac-proxy/tree/master/examples/oidc

[skabashnyuk]

First jumboard we have after internall call with platform team

https://jamboard.google.com/d/1ez2a0m---FGkSc9Ydabd76fP6m9II_RW8CvY1sXnERQ/edit?usp=sharing

[skabashnyuk]

Second jumboard

https://jamboard.google.com/d/1_MfiHuzb5Dq6_54x2jcF9emGdMW0VUaUbiLZKEw9baE/viewer

[sparkoo]

We have these entrypoints to Che, that has to be authenticated (considering single-host deployment with devworkspaces)

• proxy to kubernetes API (via traefik)
• single-host workspace endpoints (via traefik, but currently not same instance as ^)
• subdomain workspace endpoints (completely separate routes/ingresses)

[sparkoo]

We've prepared POC on minikube for "single-host" routes. See https://github.com/che-incubator/che-auth-playground/tree/master/kubernetes for the setup:

There are some issues/unanswered questions:

• kube-rbac-proxy "eats" the authorization header with bearer token. I've created an issue(Pass Authorization header with bearer token to upstream app brancz/kube-rbac-proxy#114) and proposed the PR(option to pass bearer token header to upstream brancz/kube-rbac-proxy#115) to bypass that. Waiting for the mainainers
• like this, each exposed port in workspace will need it's own kube-rbac-proxy instance. I think there's ~7 ports exposed in empty workspace, that would mean 7 extra containers for only empty workspace and +1 for every additional endpoint. I believe we could optimize by having only single entrypoint protected with kube-rbac-proxy and reverse-proxy behind to route to correct internal ports. Like this we would have 2 extra containers per workspace (now we have 1 - jwtproxy).
• for subdomain routes (a.k.a. multi-host), we would either need oauth2-proxy in front of every endpoint or we will reuse current gateway to routing these as well. That would mean to create Ingress/Route in 'che' namespace and configure the traefik so it can route based by subdomains.
• on Openshift, the only difference should be to replace oauth2-proxy with it's openshift fork (https://github.com/openshift/oauth-proxy) and leave out the Dex. Currently it's only my assumption and we need to test it [che-auth] Setup full che-like auth flow on Openshift #19358

[sparkoo]

Status update

Step 1 - Foundations (Che 32?)

We've starting working on implementation. We're now focusing only on OpenShift with DevWorkspaces.

1. Che-server In review - New che authentication support New che authentication support #19784
2. Installation with che-operator Planned next - [che-auth] - make it possible to deploy Che with new auth [che-auth] - make it possible to deploy Che with new auth #19705
3. Authorization header component Planned next - [che-auth] - oauth-proxy can't put token into Authorization header [che-auth] - oauth-proxy can't put token into Authorization header #19704

After these 3 we'll have an option to install Che on OpenShift without Keycloak and any OpenShift user will be able to login to Che and use DevWorkspaces (no devfile v1 support).

Step 2 - Workspace authentication (subpath) (Che 34?)

We will then focus on workspace authentication. At first, we'll secure subpath endpoints ([che-auth] - secure workspace subpath endpoints in new auth gateway #19707).

❗ Concern/complication

There is one concern about this! For new authentication, we need to change the deployment of the che-gateway. Currently it's "only" routing the traffic, but with new auth it will be responsible also for authentication and authorization.

We now have 2 che-gateways (Traefik):

1. installed by che-operator inside eclipse-che namespace
   - routing to che-server + other components like plugin/devfile registries
   - workspaces with devfile v1
2. installed by devworkspace-che-operator inside devworkspace-che namespace
   - routing to devworkspaces

Eech gateway has it's own Route -> devworkspaces have different hostname than che-server or devfile v1 workspace. We're currently in the process of merging these 2 operators together and having only one gateway and one Route. Ideally, we would implement workspace authentication AFTER this merger is done. Otherwise we would have to implement same functionality twice (in che-operator and devworkspace-che) and it might get complicated due to different hostname and cookies path (not verified).

Future (Che X)

• Subdomain routes
• Devfile v1 support
• Kubernetes support (Dex as identity provider)

[benoitf]

moving issue to 7.42 milestone as this issue is part of the endgame

[sparkoo]

scope of this epic is complete and all issues are close. I'm closing this. Following issues/improvements will be solved in dedicated issues.