Automatically configure an OIDC provider on major public clouds (AWS, Azure, GCP)

[l0rd]

Is your enhancement related to a problem? Please describe

Previous to Che v7.42, Che deployment included Keyloak on any platform.

With v7.42 we switched to use Kubernetes for authorization (a Che user is a Kubernetes user) but users have to manually configure their Kubernetes cluster to use an OIDC provider (except for minikube and OpenShift).

Describe the solution you'd like

We should support an automatic OIDC provider setup for a Kubernetes cluster deployed on the 3 major cloud vendors:

• AWS
• Azure
• Google Cloud Platform

Describe alternatives you've considered

No response

Additional context

When a git service is setup the OIDC provider should be configured to use the git service as an identity provider (c.f. #20583)

[cristian-radu]

Could you please support custom OIDC provider configuration as well?

We deployed Eclipse Che over 1 year ago now, when Keycloack was the authentication provider being used. We chose to deploy an external instance of Keycloack that we manage ourselves and we have tied it to other components of our platform as well.

Since the Eclipse Che Helm charts have been deprecated, we are migrating to managing our installation using the che-operator instead.

The che-operator deploys a hardcoded oauth2-proxy configuration which does not work with Keycloak.

https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider#keycloak-oidc-auth-provider

Due to the plethora of authentication providers out there, my feeling is that a custom oauth2-proxy configuration is more appropriate rather than making assumptions as to what users may have and or want to use.

[l0rd]

@cristian-radu custom OIDC providers, including Keycloak, should be supported. Can you please help us with more details about what are the problems with current OAuth2 proxy configuration? How could we make it work with Keycloak?

[cristian-radu]

@l0rd My issue was around the fact that the oauth2-proxy checks for the presence of the email_verified claim by default. In my case, the Keycloak users are federated from LDAP so it does not make too much sense to me to add this claim, but I did it anyway. So now I have Keycloak sending email_verified = true which resolved my issue without changing the proxy configuration.

However, I still think it is valuable to users to be able to change the configuration of the oauth2-proxy. Maybe the operator can just deploy a working default config and have some mechanism by which it will ignore config changes made by the user. That to me sounds like a good middle-ground as opposed to enforcing a hardcoded config.

For example, I'm not too happy about having insecure_oidc_skip_issuer_verification = true and ssl_insecure_skip_verify = true. I would rather have a specific email_domains list rather than a wildcard. Would also like to be able to specify which LDAP groups are allowed to authenticate against Che rather than allowing all.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[l0rd]

/remove-lifecycle stale

[tolusha]

Closed in favor of #22392