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.
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.
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 :)