Zero-to-jupyterhub-k8s: Authenticator not honoring the auth.whitelist.users key

[TiemenSch]

Bug description

The user whitelist is not being honored when using the Gitlab OAuthenticator.

Expected behaviour

Only users in the whitelist should be able to login to the JupyterHub.

Actual behaviour

Any (Gitlab) user is able to login and use the JupyterHub instance.

How to reproduce

Try logging in with a account not in the whitelist.

Your personal set up

auth:
  whitelist:
    users:
      - user1
      - user2
  admin:
    access: true
    users:
      - <REDACTED>
  type: gitlab
  gitlab:
    clientId: <REDACTED>
    clientSecret: <REDACTED>
    callbackUrl: <REDACTED>
  scopes:
    - "read_user"

• OS: Linux
• Version: Chart 0.10.2
• Configuration: See above.

[welcome[bot]]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! :wave:

Welcome to the Jupyter community! :tada:

[TiemenSch]

Ah, this appears to be related to JupyterHub's own changelog which moved the whitelist management to the config key allowed_users.

https://jupyterhub.readthedocs.io/en/latest/changelog.html?highlight=whitelist#id3

Setting them using the c.Authenticator.allowed_users works.

Although this is slightly confusing as the whitelist key in the Helm chart still exists, but does not appear to do anything.

[manics]

It looks like the current chart sets c.Authenticator.whitelist:
https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/f34bf9950841bedba76174a7d1c5c21e4ecbbb18/jupyterhub/files/hub/jupyterhub_config.py#L391

Although the property is deprecated in JupyterHub, there should be logic to still use the original property if the new property isn't set.

[TiemenSch]

I guess that line should now say:

set_config_if_not_none(c.Authenticator, 'allowed_users', 'auth.whitelist.users') 

for newer versions?

Or is allowed users a substantial different property w.r.t. the old whitelist?

[manics]

I think that would work, there's no change to the format of the value.

However I'm still concerned that it's not currently working for you. Backwards compatibility was deliberately included in the relevant PRs:

• https://github.com/jupyterhub/jupyterhub/pull/3090
• https://github.com/jupyterhub/oauthenticator/pull/366

[TiemenSch]

From a security perspective this isn't very nice, but luckily in my case it was a deployment for a relatively small course on uni where users only had access to their own volumes and no other sensitive resources.

For full disclosure: I do have custom initContainers and some other settings set, but I don't think these come into play until after authentication has succeeded?

Some additional remarks:

Any chance the logic of the Gitlab OAuthenticator and the allowed groups or allowed projects may interfere in this specific case?

Is there a test in place that still tests a config with the old whitelist config key in place?

Besides debugging the code directly, would you know of any messages that I can find in my logs from the past days that may be helpful to investigate this further? I couldn't find any myself and I guess there probably isn't one stating the whitelist now and again. The only one that may be vaguely remotely related that I could find was related to some ConfigMap:

2020-11-18 14:50:52 
E1118 13:50:52.360639 1 reflector.go:127] k8s.io/apiserver/pkg/server/dynamiccertificates/configmap_cafile_content.go:206: Failed to watch *v1.ConfigMap: failed to list *v1.ConfigMap: configmaps "extension-apiserver-authentication" is forbidden: User "system:serviceaccount:jhub:user-scheduler" cannot list resource "configmaps" in API group "" in the namespace "kube-system" 

[naterush]

To add on here, I'm currently using the following config:

auth:
  type: google
  google:
    clientId: ...
    clientSecret: ...
    callbackUrl: ...
  whitelist:
    users:
      - user1
      - user2

However, the signin is letting _anyone_ sign in with google not just these accounts. Is there a workaround, or is the whitelist field just non-functional?

Thanks!

[naterush]

Workaround is the following. First:

1. Remove the whitelist field from the auth.
2. Add the following:

hub:
  extraConfig: |
    c.Authenticator.allowed_users = {
      user1, 
      user2
    }

[minrk]

@TiemenSch we've tracked it down and will release oauthenticator 0.12.2 with the fix. the helm chart 0.10.6 is already out with a fix. The only affected issue is the deprecated user whitelist configuration was not honored due to a relationship between the base class provided by jupyterhub (where the allowed_users set is implemented) and oauthenticator (where other mechanisms are implemented). Other provider-specific deprecations function as intended. You can confirm this in your Hub logs if you see messages about deprecated configuration.

@naterush is right that extraConfig to set the allowed_users set directly will work. You could also directly call our set_config_if_not_none utility, e.g.

hub:
  extraConfig:
    allowedUsers: |
        # map deprecated helm field to current Authenticator field
        set_config_if_not_none(c.Authenticator, "allowed_users", "auth.whitelist.users")
        # passthrough new field
        set_config_if_not_none(c.Authenticator, "allowed_users", "auth.allowedUsers")

[consideRatio]

Thanks @minrk for summarizing this! The Helm chart versions that have this problem are 0.10.0 -> 0.10.5. Thank you @TiemenSch for reporting this!

[TiemenSch]

Glad this got sorted out :)! I was afraid at first it might have been due to my own additional config in some way.

I guess the Helm fields make things convenient at times, but are one more layer of 'potential communication errors' to keep up with at others.

I'm starting to appreciate the extraConfig key more, as it provides a nifty shortcut to the complete config.py approach that is native to Jupyter(Hub).

[minrk]

We're also working on resolving these issues in #1871 which looks like we will make helm config for auth a bit more explicit if a bit more verbose.