Automate the setup of github identity provider with internal keycloak

[benoitf]

Is your enhancement related to a problem? Please describe.

Today, we've some plug-ins that allow to do easy things with github repositories. You just need to click on a button to authenticate on github.
But it works only if the github identity provider is correctly setup on the keycloak instance.

Describe the solution you'd like

Automate the creation of the github oauth apps or ease the way on adding github identity provider when installing che with a local keycloak instance

Describe alternatives you've considered

If creation can't be automated from a github token, allow to specify github client id and secrets

Additional context

The goal is to have workspaces ready to use github integration after a first install of Eclipse Che.

https://www.keycloak.org/docs/latest/server_admin/#github
https://www.eclipse.org/che/docs/che-7/end-user-guide/configuring-github-oauth/

$ /opt/jboss/keycloak/bin/kcadm.sh create identity-provider/instances -r che -s alias=github -s providerId=github -s enabled=true -s storeToken=true -s 'config.useJwksUrl="true"' -s config.clientId=GITHUB_CLIENTID -s config.clientSecret=GITHUB_CLIENTSECRET -s 'config.defaultScope="repo,user,write:public_key"' --server http://0.0.0.0:8080/auth --realm master --config /scripts/.keycloak/kcadm.config

[tolusha]

@benoitf
Do you know any apps that creates github oauth apps ?
I tend to implement the alternative solution

[benoitf]

Hello Anatolii, after creating the issue I searched and it seems the short answer is 'no' (there is no API)

so the idea would to create a hosted 'che oauth github app' that would redirect to the 'local-instance callback' at the end. And the local-instance should be a parameter (like using local-storage to pass the URL to redirect to)

and then in keycloak it will had this 'one for all' che-oauth-github-app

[tolusha]

@benoitf
I am not sure If I understand your idea about hosted things ^(

[benoitf]

@tolusha

let say I go to github and I register a new che oAuth github page with callback http://che-incubator.github.io/chectl/oAuth.html

then I grab the id of this app and I use it in all chectl providing a flag to use automatic github oAuth

Then when it will call oAuth it needs to provide to http://che-incubator.github.io/chectl/oAuth.html a special parameter/local-storage file, whatever, which will be the 'che URL' to redirect to

As a client it will do : login on che--> redirect to github oAuth --> goes to http://che-incubator.github.io/chectl/oAuth.html , see that there is a parameter and then redirect to http://my-che-instance.com

[tolusha]

So, does it mean that http://che-incubator.github.io/chectl/oAuth.html can be used by different Eclipse Che deployments ?
How we should handle the case with different che URLs ?

[tolusha]

@benoitf @l0rd

This PR [1] is indented to automatically provision github identity provider.
User should create the following secret in che namespace:

kind: Secret
apiVersion: v1
metadata:
  name: github-credentials
  namespace: che
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: keycloak-secret
  annotations:
    che.eclipse.org/github-oauth-credentials: "true"
    che.eclipse.org/mount-as: env
    che.eclipse.org/githubId_env-name: GITHUB_CLIENT_ID
    che.eclipse.org/githubSecret_env-name: GITHUB_SECRET
data:
  githubId: <..>
  githubSecret: <..>
type: Opaque

Regarding the part about creation hosted script to redirect to che instance.
@sleshchenko @skabashnyuk have security concerns about that.
We can discuss it in a dedicated issue.

[1] eclipse-che/che-operator#589

[l0rd]

@tolusha what about setting app.kubernetes.io/component to github-oauth-credentials (and removing annotation che.eclipse.org/github-oauth-credentials)?

  (...)
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: github-oauth-credentials
  annotations:
    che.eclipse.org/mount-as: env
    che.eclipse.org/githubId_env-name: GITHUB_CLIENT_ID
    che.eclipse.org/githubSecret_env-name: GITHUB_SECRET
(...)

[tolusha]

There are two points why I prefer:

  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: keycloak-secret
  annotations:
    che.eclipse.org/github-oauth-credentials: "true"

1. Labels like this app.kubernetes.io/component: <DEPLOYMENT>-secret & app.kubernetes.io/part-of: che.eclipse.org allow to mount a secret in a corresponding container independently of annotations. It is based on the feature Mount secrets in containers che-operator#595 that has been implemented recently (the doc in progress)
   The annotation che.eclipse.org/github-oauth-credentials: "true" just indicates to provision GitHub OAuth.

2. To follow the same pattern as described here
   https://www.eclipse.org/che/docs/che-7/end-user-guide/mounting-a-secret-as-a-file-or-an-environment-variable-into-a-workspace-container/#mounting-a-git-credential-store-into-a-workspace-container_mounting-a-secret-as-a-file-or-an-environment-variable-into-a-workspace-container

[l0rd]

@tolusha ok it makes sense to keep the app.kubernetes.io/component: keycloak-secret then.

Anyway it looks like you have implemented a generic mechanism to inject secrets in che-server pods. And that the GitHub OAuth is an example of usage of such a mechanism. We need to make it clear in the documentation.

That was not really required to fix this issue but it's indeed a good idea to have such a generic mechanism.