Filter environments by user access

[soapy1]

This PR updates the get_conda_environments function called by jhub apps so that only the environments the user has access to are shown. This is achieved by generating a token for permissions that match the jupyterhub users' conda-store permissions.

Reference Issues or PRs

#2193

What does this implement/fix?

Put a x in the boxes that apply

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds a feature)
• Breaking change (fix or feature that would cause existing features not to work as expected)
• Documentation Update
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build related changes
• Other (please describe):

Testing

• Did you test the pull request locally?
• Did you add new tests?

How to test this PR?

0. To test this PR you must have
   a. an installation of Nebari with jhub apps enabled
   b. at least 2 users with some conda environments
1. Log in as the first user
2. Navigate to the nebari home screen
3. Click on the deploy app button
4. Click on the drop down to select the conda store environment for the app
5. Notice that all the environments the user has access to are available - that is default environments + its own environments, but not environments from the second user
6. Repeat for the second user

[soapy1]

There is a pretty big assumption here, that the keycloak groups map directly to the conda-store namespaces. Is that true for nebari?

[dcmcand]

There is no direct way to create a new namespace through the ui, and group names do match namespaces, though there is also a namespace per user that matches their user name.

That being said, it is possible to create a new namespace and give permissions to use it with an arbitrary name using the conda-store api.

Additionally, some groups, like admins, have access to more namespaces than just their own.

[soapy1]

Is there a doc (or piece of existing code) that describes the relationship between keycloak permissions/groups/etc and conda-store privileges? I want to be able to ensure the user is able to see all the namespaces+environments it has access to.

[dcmcand]

There is custom auth logic at

nebari/src/_nebari/stages/kubernetes_services/template/modules/kubernetes/services/conda-store/config/conda_store_config.py

Line 105 in ac88391

class KeyCloakCondaStoreRoleScopes:

which does the mapping

[soapy1]

hmmm, I see that's not quite what I'm looking for. The user_info dict provided ultimately comes from the jupyter api /users endpoint https://jupyterhub.readthedocs.io/en/5.2.1/reference/rest-api.html#operation/get-user which provides the users roles and groups. Here is an example of the output

{
  "name": "string",
  "admin": true,
  "roles": [
    "string"
  ],
  "groups": [
    "string"
  ],
  "server": "string",
  "pending": "spawn",
  "last_activity": "2019-08-24T14:15:22Z",
  "servers": {
  },
  "auth_state": {}
}

Is there some piece of code or docs that describe the relationship between hub users and keycloak users or conda store permissions?

[dcmcand]

@viniciusdc do you have any insight here for @soapy1?

[krassowski]

relationship between hub users and keycloak users

Chiming in as I worked on this - both groups and roles are taken from Keycloak since:

• Get JupyterHub groups from Keycloak, support oauthenticator 16.3+ #2361
• Fetch JupyterHub roles from Keycloak #2447

@viniciusdc can confirm if anything changed since as I was not reviewing PRs that followed, but I suspect this is still the case.

[soapy1]

Thanks @krassowski those links were very helpful in piecing together a model of what is going on here. This part of the authenticator is also notable https://github.com/nebari-dev/nebari/blob/main/src/_nebari/stages/kubernetes_services/template/modules/kubernetes/services/conda-store/config/conda_store_config.py#L415.

I think this implementation where the permissions are constructed based on the group provided by the Jupyter user object should be correct. I added a few extra comments to explain the motivation.

This was pretty convoluted to piece together. I think it would be good if at least one other person also went thru the exercise of following the permissions flow from keycloak thru Jupyter and conda-store to double check that this approach is valid.

It would be nice if there was some kind of document that outlined the intended design of how permissions work in nebari. Maybe as part of the tasks in this issue #2304?

[dcmcand]

@soapy1 this works great on a new deploy, but doesn't work if you have an existing deploy. If you have an existing deploy and upgrade you can still see all of the envs in jhub-apps.

[soapy1]

Thanks @dcmcand for testing this out!

but doesn't work if you have an existing deploy. If you have an existing deploy and upgrade you can still see all of the envs in jhub-apps.

I think I'm going to need a bit more information in order to debug this. In particular:

• what version of nebari did you start with?
• how did you upgrade?
• is this behaviour true for all users, or for a set of users with some characteristic?
• what are the keycloak groups that the offending user is part of? are they an admin?
• what version of keycloak is running?

[dcmcand]

🚀

[marcelovilla]

@dcmcand tested this again and did not run into the issue that was mentioned before. Thus, I'm merging this.

Thanks @soapy1 🚀 !