nebari icon indicating copy to clipboard operation
nebari copied to clipboard

[ENH] - Create shared directory only if group has permissions

Open aktech opened this issue 1 year ago • 1 comments

Feature description

At the moment, when a group is created in Keycloak, a shared directory is created for that group in the NFS, example:

akumar:~ 
05:04 $ ls shared/ -ltrh
total 8.0K
drwxrwxrwx 4 0 0 4.0K Feb 14 12:34 analyst
drwxrwxrwx 6 0 0 4.0K Apr 12 06:17 developer

Based on the groups the user is present in, the user have access to those.

We need to change this behaviour such that the shared directory is only created if a keycloak role with following attributes is attached to the group:

Role: create-shared-directory (name is only for example, it could be arbitrary)

Key Value
resource shared-directory
scopes write:shared

This issue is part of the permissions RFD: https://github.com/nebari-dev/governance/issues/47

Notes for implementation:

  • We would need to filter groups with roles here: https://github.com/nebari-dev/nebari/blob/3e0f41d6a0f48194e7962c9c260c46fdc2472f52/src/_nebari/stages/kubernetes_services/template/modules/kubernetes/services/jupyterhub/files/jupyterhub/03-profiles.py#L130
  • To make this backwards compatible we need to make sure that this role is applied to default groups we currently create in Nebari
  • The edge case where a group had the above role and was later the role was removed from it: the shared directory for the same should not be removed as it could have user data and that might get lost and cause unexpected behaviour.
  • All the roles should be client specific, as in it should be part of a client like jupyterhub, grafana, conda_store, etc. In this case the role should be part of jupyterhub client. See example below (keycloak screenshot):
Screenshot 2024-04-30 at 11 27 38 am

Value and/or benefit

This gives us the ability to selectively created shared directory for keycloak groups as the user might not want to create shared directory for every group they create in keycloak.

Anything else?

No response

aktech avatar Apr 30 '24 10:04 aktech

Just a quick update on this.

I've finished refactoring the parser to spawner.py to handle the new role scopes for the mounts (I used the sample response shared here) and added the new roles for backward compatibility for analyst, developer, admin (I got a minor error with terraform, currently addressing it).

The only thing that needs to be added is getting the actual dict containing the roles from the Keycloak authenticator within the spawner. There is a function already present within the spawner that should allow to get the loaded_roles as part of the user metadata, I will be testing this today.

viniciusdc avatar Jul 02 '24 15:07 viniciusdc