Disable OIDC provider and enable it post installation through installer=operator

[abhijeetka]

Summary

Che Version: 7.51.0 Chectl Version : 7.51.0

While installing we are using chectl with --skip-oidc-provider-check and the pods are up however the che pods are trying to use the default oidc provier.

However, we want eclipce-che to use some other oidc provider however we are not sure how to provide that, we went through the documentation and we observered to edit the CRD checluster however the documentation provided is for org.eclipse.che/v1 and we are using org.eclipse.che/v2

Please guide us to the appropriate documentation or share the URL's which can help us to fix this problem.

Thanks in Advance

Relevant information

No response

[ibuziuk]

@tolusha could you please take a look?

[tolusha]

Hello. @abhijeetka

To use a custom OIDC provider:

1. create a patch file

$ cat > che-patch.yaml << EOF
kind: CheCluster
apiVersion: org.eclipse.che/v2
spec:
  networking:
    auth:
      oAuthClientName: <CLIENT_ID>
      oAuthSecret: <CLIENT_SECRET>
      identityProviderURL: <IDENTITY_PROVIDER_URL>
  components:
  # Some OIDC providers might require it
  #  cheServer:
  #    extraProperties:
  #      CHE_OIDC_USERNAME__CLAIM: email
EOF

2. Deploy Eclipse Che using chectl providing the patch file

chectl server:deploy --platform k8s --domain <KUBERNETES_PUBLIC_DOMAIN> --che-operator-cr-patch-yaml che-patch.yaml

For instance we have a draft doc explaining how configure Minikube with a Keycloak as OIDC provider and deploy Eclipse Che https://github.com/eclipse-che/che-docs/pull/2408

[abhijeetka]

@tolusha I will give it a try today.

[vkatta88]

Hi,

We tried installing with the above given hint.

We have created the che-patch.yaml with the below content.

kind: CheCluster
apiVersion: org.eclipse.che/v2
spec:
  networking:
    auth:
      identityProviderURL: https://sts.windows.net/{TENANTID}/v2.0/
      identityToken: access_token
      oAuthClientName: {CLIENTID}
      oAuthSecret: {CLIENTSECRET}
      oAuthScope: openid email profile
  components:
    cheServer:
      extraProperties:
        CHE_OIDC_AUTH__SERVER__URL: https://sts.windows.net/{TENANTID}/v2.0/
        CHE_OIDC_EMAIL__CLAIM: unique_name

we are using AWS EKS cluster. After adding the above OIDC Azure AD details able to resolve che dashboard URL but it is keep on loading the dashboard page and throwing the error 'Failed to fetch available workspaces, reason: Failed to fetch the list of devWorkspaces. Unable to list devworkspaces: Unauthorized'

Please check and let us know what needs to be modified. Thanks in advance

[tolusha]

@vkatta88

'Failed to fetch available workspaces, reason: Failed to fetch the list of devWorkspaces. Unable to list devworkspaces: Unauthorized'

I can see this kind of error when CHE_OIDC_EMAIL__CLAIM set incorrectly. Could you check RoleBinding in a user namespace?

oc get rolebinding eclipse-che-cheworkspaces-clusterrole -n <NAMESPACE> -o yaml oc get rolebinding eclipse-che-cheworkspaces-devworkspace-clusterrole -n <NAMESPACE> -o yaml

[vkatta88]

@tolusha

For the parameter CHE_OIDC_EMAIL__CLAIM we have used both 'unique_name' and 'email'..

As requested please find the below cluster role bindings and here we are using kubernetes cluster (EKS).

eclipse-che-cheworkspaces-devworkspace-clusterrole:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: "2022-08-11T11:54:06Z"
  name: eclipse-che-tenant703257-cheworkspaces-devworkspace-clusterrole
  namespace: vkatta-company-com-che-372ps6
  resourceVersion: "104343008"
  uid: 53f35252-8f39-4555-a475-41332dd9b203
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: eclipse-che-tenant703257-cheworkspaces-devworkspace-clusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: [email protected]
  namespace: vkatta-company-com-che-372ps6

eclipse-che-cheworkspaces-clusterrole:

kind: RoleBinding
metadata:
  creationTimestamp: "2022-08-11T11:54:06Z"
  name: eclipse-che-tenant703257-cheworkspaces-clusterrole
  namespace: vkatta-company-com-che-372ps6
  resourceVersion: "104343009"
  uid: ae5f6c81-e46e-4889-9998-4e88e501189f
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: eclipse-che-tenant703257-cheworkspaces-clusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: [email protected]
  namespace: vkatta-company-com-che-372ps6

We have also tried with below option but no luck

extraProperties:
        CHE_OIDC_USERNAME__CLAIM: email

Please check and let us know. Thanks in advance

[abhijeetka]

@tolusha we are working on eks cluster and there also they provide oidc, is it something that causing this issue?

However I checked, and there is no oidc provided configured for my cluster. aws iam list-open-id-connect-providers | grep *******

So now a Kubernetes cluster which does not have oidc provider and we are installing eclipse che, with external oidc provider as azure, the login works fine but posts that we are getting the above issue mentioned by @vkatta88.

We are stuck, earlier we were using 7.31.0 version but it's too old now. We need the latest and with azure ad integration.

[vkatta88]

@tolusha Do you have any update on this please? we are stuck here.

[abhijeetka]

@ibuziuk @tolusha @che-bot we are stuck here and no further things to try.

[tolusha]

To be honest I don't think it can work if there are no any identity providers on the cluster Maybe @amisevsk @sparkoo have some ideas.

[sparkoo]

you have to have configured oidc provider for your cluster and same oidc must be used for Che. It's used to authenticate and authorize users, so there is no way around it.

[LiJunBJZhu]

Is it possible to configure one OIDC provider, for example, named A, for the cluster but limit the access of Openshift users so that only the users from the oidc provider A can access to the checluster, but not all Openshift cluster users can access it since the cluster may have multiple oidc providers configured. @amisevsk @sparkoo @tolusha.

[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.