Organization-based GitHub authentication not working

[ablekh]

I might be missing something or doing something wrong, but it seems that relevant value in config.yaml configuration file for Helm has no expected effect on GitHub-based authentication. Here is how relevant section looks in my configuration file:

auth:
  type: github
  github:
    clientId: "<ID>"
    clientSecret: "<SECRET>"
    callbackUrl: "<URL>"
    org_whitelist:
      - "<MY_ORG>"
    scopes:
      - "read:org"

I have also tried documentation-recommended read:user scope, but it had the same effect of allowing any GitHub user to be able to authenticate and use our JupyterHub instance. I was expecting that access to the instance would be limited to users, belonging to defined set of white-listed organizations (in this case, only MY_ORG, for now). However, this is not happening. As always, your help / advice will be much appreciated.

[consideRatio]

@ablekh hmmm I recall something very similar being discussed somewhere... Related to github organisations and the read: scopes.

[ablekh]

@consideRatio Thank you for the hint. I forgot to search existing issues in this repo (both open and closed). Just searched and only discovered #687. Which is interesting, but still is not helpful in terms of the solution.

[betatim]

I have a few hubs running with the following:

  auth:
    type: github
    github:
      callbackUrl: "https://example.com/hub/oauth_callback"
      org_whitelist:
        - "wildtreetech"
    scopes:
      - "read:user"

and as far as I can tell that works :-/ Will double check.

[ablekh]

@betatim Thank you for your feedback. Positioning of the scopes attribute in your snippet looks pretty suspicious to me, since it is indented outside of the github scope (no pun intended). When you say that works, does it imply that only auth requests of members of the wildtreetech organization are approved?

[manics]

@ablekh @betatim's config looks correct. scopes comes under auth since other OAuthenticators can make use of it, though the actual values it can take are specific to the auth type.

edit: Confirmed the docs look correct: https://zero-to-jupyterhub.readthedocs.io/en/latest/authentication.html?highlight=github#giving-access-to-organizations-on-github

[ablekh]

@manics Thank you for your clarification. Any thoughts on why a correct auth config might not work?

[manics]

@ablekh I just realised by previous comment might have been ambiguous, can you confirm your current config has scopes under auth, not under github? Which version of z2jh are you using?

[ablekh]

@manics I confirm that I have tested all types of Helm configuration, including ones, containing scopes under auth (one with "read:user", another with "read:org"). Neither of them have worked. I use v0.6.

[manics]

auth.scopes was added after the v0.6 release: #523

Could you try with a v0.7 dev release from https://jupyterhub.github.io/helm-chart/#development-releases-jupyterhub ? Bear in mind this may includes a upgrade to jupyterhub 0.9, though if this is just a test deployment it shouldn't matter.

I think having https://zero-to-jupyterhub.readthedocs.io/ default to latest is confusing when it doesn't match the latest jupyterhub release... I'll open a separate issue.

[ablekh]

@manics I appreciate your helpful advice. Unfortunately, this JupyterHub instance is a production one, so I'm a bit hesitant to use a non-GA v0.7 release on it. The problem is not the Helm release per se (as I can easily roll back to v0.6), but, as you mentioned, a potential upgrade to JH v0.9. I can think of one additional benefit of such upgrade - I would likely get a custom image / kubespawner profiles functionality. However, what are potential risks associated with that upgrade?

[manics]

Sorry, can't help with the risks, maybe @consideRatio can?

[consideRatio]

@ablekh Hmmm, I'm not sure about the JupyterHub 0.8 to 0.9 upgrade. The JupyterHub changelog documents that it is recommendeds a backup of the db before and an execution of jupyterhub upgrade-db after the upgrade.

Are you using the default z2jh helm chart database @ablekh? Using storage claimed by the hub-db-dir pvc that is?

Perhaps one can make backup of these smoothly somehow? Hmm... All in all I don't know much. Perhaps @minrk has some input regarding a helm chart upgrade from 0.6 to 0.7 and the associated jupyterhub upgrade from 0.8 to 0.9?

[betatim]

If you are using the helm chart you should be able to fairly easily make a second deployment in a new namespace using the new helm chart version and test things out there. Basically a "staging" hub.

[ablekh]

@manics No problem. Thank you for your help.

[ablekh]

@consideRatio Thank you very much for trying to help. I use default settings. It sounds like the advice by @betatim (see above) is most likely the optimal as well as straightforward and safe enough to go with.

[ablekh]

@betatim It seems that your advice is the optimal one as well as straightforward and safe enough to go with. I appreciate your help.

[ablekh]

BTW, do you, guys, know what is the planned date for releasing Helm chart v0.7?

[consideRatio]

@ablekh your welcome! I sadly don't have a release date for the chart, but it would be great to make a release. We have discussed making one as soon as possible.

I'm spending a lot of time now doing work on the repo. Hope to push it closer but it is quite a bit of documentation etc that needs to be done that feels a bit much currently for me to estimate.

[ablekh]

@consideRatio Understood. I appreciate all the work that core team has done. Let me know, if I can help.

[betatim]

Looks like this is resolved so closing. Feel free to re-open if that impression is wrong.

[ablekh]

@betatim @consideRatio Quick question: how am I supposed to reference a specific JH Helm chart development release when installing the chart in a separate namespace (per @betatim's advice)? E.g.:

helm install jupyterhub/jupyterhub \
    --version=v0.7-578b3a2 \
    --name=sbdh-jh-v4 \
    --namespace=sbdh-jh-v4 \
    -f config.yaml

@yuvipanda @choldgraf Perhaps, you could reply quicker, depending on TZ and stuff ...