Restrict profile_list options depending on the user

Context

Our profile_list config lets us define a subset of “configuration over-rides” that change the behavior of the user environment with launch.

For hubs that have different groups of users, they may want to allow only a subset of user profiles to be accessible to certain groups of users. For example:

• all-users: have access to a basic 2 GB RAM environment with a base image
• power-users: are those trusted not to accidentally generate high costs, and have access to a 32GB RAM environment with a machine learning image

Proposed change

We should make it possible for a hub’s profile_list to specify groups of users that have access to different subsets of profiles. A user’s membership in a group would determine the profiles that are available to choose from when they hit the profile_list selection page.

Suggest a solution

I am not sure on this, but perhaps the upcoming RBAC functionality in JupyterHub could be used to define the user groups, and this could be mapped on to a given subset of profiles?

For example, we could add a user_groups flag to the profile_list config, e.g.:

c.KubeSpawner.profile_list = [
    {
        'display_name': 'Training Env - Python',
        'slug': 'training-python',
        'user_groups': ['all-users'],
        'default': True,
        'kubespawner_override': {
            'image': 'training/python:label',
            'cpu_limit': 1,
            'mem_limit': '512M',
        }
    }, {
        'display_name': 'Training Env - Datascience',
        'slug': 'training-datascience',
        'user_groups': ['power-users', 'admins'],
        'kubespawner_override': {
            'image': 'training/datascience:label',
            'cpu_limit': 4,
            'mem_limit': '8G',
        }
    ...

Updated plan

We decided it would be best not to implement a technical solution to this, for fear of making the configuration etc too complex to maintain and use. Instead, we’ll add documentation to @consideRatio’s post for how to do this with some custom python code:

• Like done in this mybinder documentation, link out to the forum post on how to configure spawn options based on custom logic from somewhere in this repo’s docs.

[consideRatio]

This is a very common feature request that has come in many variations so I’m hesitant to implement logic about it tailored for a specific variation.

There is a general strategy that can be used, no matter if it should be based on groups or something else that I wrote about in https://discourse.jupyter.org/t/tailoring-spawn-options-and-server-configuration-to-certain-users/8449.

Looking through issues i find these that seem related:

• https://github.com/jupyterhub/kubespawner/issues/439
• https://github.com/jupyterhub/kubespawner/issues/307

[benjimin]

I think it would be good to implement some logic concerning this (e.g. let profiles each optionally specify a list of user groups, and only offer those profiles to users who belong to one of those groups).

The problem with recommending extensive custom code (to be inserted via helm) is that it is very difficult to test and debug. For example, I’m currently attempting to debug an issue whereby starting a server with a specific profile (which uses a customised image, and is supposed to be restricted to a subset of users via aws-cognito) seems to poison the spawner such that immediately subsequent attempts to spawn the default server will unexpectedly also use the same customised image. The docs are simply referring me back to this snippet of code hosted at discourse, meaning there is also no version control and limited scope to propose fixes to the code or documentation or test suite, for this common use-case. (It also doesn’t feel like best practice for security to inject arbitrary python via helm & k8s resources?)