jupyterhub/helm-chart

Getting the gitlab authenticator working against jupyterhub 0.8x

Analect opened this issue · 3 comments

I use a self-hosted gitlab as an authenticator and wanted to get it working with the 0.5x branch of this repo, which is evidently compatible with v0.8x of the hub.

While various authenticators from oauthenticator are handled in here, gitlab isn't explicitly, so some of the following changes are necessary.

/images/hub/jupyterhub_config.py: added handling for gitlab. While the github authenticator uses c.JupyterHub.authenticator_class = 'oauthenticator.GitHubOAuthenticator', I found it was necessary to use 'oauthenticator.gitlab.GitLabOAuthenticator' for gitlab, otherwise it was complaining about not being able to import the class.

elif auth_type == 'gitlab':
    c.JupyterHub.authenticator_class = 'oauthenticator.gitlab.GitLabOAuthenticator'
    c.GitLabOAuthenticator.oauth_callback_url = get_config('auth.gitlab.callback-url')
    c.GitLabOAuthenticator.client_id = get_config('auth.gitlab.client-id')
    c.GitLabOAuthenticator.client_secret = get_config('auth.gitlab.client-secret')

/jupyterhub/templates/hub/configmap.yaml: added in handling for gitlab.

{{ if eq .Values.auth.type "gitlab" -}}
  auth.gitlab.client-id: {{.Values.auth.gitlab.clientId | quote}}
  auth.gitlab.client-secret: {{.Values.auth.gitlab.clientSecret | quote}}
  auth.gitlab.callback-url: {{.Values.auth.gitlab.callbackUrl | quote}}
  {{- end }}

In previous incarnations of running jupyterhub on kubernetes, it was necessary to pass environment variables such as GITLAB_CLIENT_ID, GITLAB_CLIENT_SECRET and OAUTH_CALLBACK_URL as key:value pairs in the deployment.yaml, which would then allow them to be surfaced as environment variables on hub and then accessed in the running jupyterhub_config.py. As I understand it, this has changed with all these settings getting automatically passed to a series of config files in /etc/jupyterhub/config and jupyterhub_config.py now accesses the values from there. The only exception is that GITLAB_HOST should still be passed as a key:value into the deployment.yaml, which I'm doing via a hub.extraEnv.

So my config.yaml looks something like this:

hub:
  cookieSecret: "xxx"
  image:
    name: my-private-registry/jupyterhub-k8s
    tag: v0.8.0b5_ns_gl
  extraEnv:
    GITLAB_HOST: "https://my-self-hosted-gitlab.com/"

proxy:
  secretToken: "xxxx"

singleuser:
  image:
    name: my-private-registry/k8s-singleuser-sample
    tag: v0.8.0b5

auth:
  type: gitlab
  gitlab:
    callbackUrl: "http://jupyterhub-ip.com/hub/oauth_callback"
    clientId: "xxxx"
    clientSecret: "xxxx"
#    gitlabHost: "https://my-self-hosted-gitlab.com/"
#    gitlabApiUrl: "https://my-self-hosted-gitlab.com/api/v3/"

admin:
  users:
    - testuser

On the hub image, I have installed the latest 0.7.0-dev version of oauthenticator alongside the latest 0.8.0b5 version of hub. It is also using a relatively recent version of kubespawner (@fa874329f).

With these various changes implemented ... while I'm being correctly directed to an orange gitlab login button, whatever inter-change is happening after that is failing and I'm not being presented with the GITLAB_HOST for authentication.

image

Is it obvious to any user with this working against v0.8x of the hub and using gitlab authentication if I'm missing something. I have the same set-up implemented that works fine against v.0.7.2 of the hub ... so somehow something has changed and I'm not handling it properly.

Thanks.

Does the gitlab authenticator work outside of the helm-chart? It could just be having problems with JupyterHub 0.8...

The two patches you mentioned for supporting gitlab seem right to me, so if you make a PR I'll happily merge :)

@yuvipanda ... no, I haven't been able to get the gitlab authenticator working against JupyterHub 0.8 outside the helm-chart either ... I have had a strange situation where if I have already been directly logged in to gitlab in the same browser that I'm starting the hub, I sometimes somehow get beyond this 400 error and hit a 500 error. I haven't been able to reproduce this behaviour consistently though.

image

OK, I'll send through a PR .. but wanted to get things running first ... so I can include any other variations. I've also added an issue on the oauthenticator here which might need more precise handling.

I'm going to close this one here since this probably belongs on the OAuthenticator repo now. We've also merged this repo into https://github.com/jupyterhub/zero-to-jupyterhub-k8s, so new discussions should happen there! Thank you :)