[ENH] - Enable scoped access to specific shared folders

iameskild commented 2 years ago

Feature description

Currently anyone who has access to a particular shared folder, say ~/shared/<my_folder>, has either complete R/W access or the folder is hidden from them. It would be great to enable scoped access to this folder such that one privileged user has R/W access while another less-privileged user only has R.

Value and/or benefit

This would make the filesystem behave more like the linux filesystem (though not exactly). Enabling this kind of scoped access allows admins and managers to shared important data without fear that it will be modified.

Anything else?

This is based on a conversation that @viniciusdc @costrouc and I had recently.

For each user (example chris) several group folders are mounted into /shared/ . For my pod jupyterlab yaml within the volumeMount section we would mount a specific group mount (the shared) as read only. This would not apply to other users. Thinks of this as an override to a particular mount saying intead of r/w make this one r. This is possible and something we could support. Question would be for me is how would this tie into authentication/authorization. Is this similar to github teams where there is team maintainer and member. E.g. we should be able to annotate that a particular user is read only within a group. This is something that conda-store could benifit from as well.

The point about authorization is good one! Would this be handled via client roles in keycloak? I’m just having a hard time imagining where the admin would make these changes.

Yeah not totally sure. Something that we'd need to talk through. I think this is a good use case for user attributes within keycloak. Though we could have roles like you said e.g. datascience-readonly, datascience-member. Not sure how we'd handle this

costrouc commented 1 year ago

Love this issue :heart:. I've already implemented most of this logic before in qhub-hpc the "on prem systemd nebari" which we haven't spent as much time on https://github.com/Quansight/qhub-hpc/blob/2f9e6f75fefae20bedf47608b7a474b779475da0/roles/jupyterhub/templates/jupyterhub_config.py#L68-L105. However there are significant improvements we can make on this code in nebari. The one that stands out to me is that we make the jupyterhub keycloak oauth2 client capable of being a service account. This will allow jupyterhub to use it's oauth credentials to modify users/groups without admin credentials (which we never should have been doing in the first place).

Steps that I see:

Store uid/gid on keycloak

High level we need to store a unique uid attribute associated with each user and unique gid attribute for each group that the user is a member of. The code above shows how to store these attributes. The trick is that you have to ensure that the uids are unique and gids are unique. I guess collisions aren't that bad but since we can avoid them we should. We should avoid randomly generating the ids to maximize the stability of uids when users are removed/added back. Also a fixes set of uid/gids should be protected. E.g. less than 1000000.

Steps to launch jupyterlab cluster

When user launches a jupyterlab cluster we need to ensure:

chown the user home directory and group directory with correct permissions
/etc/passwd, /etc/group have the right name/uid/gid mappings https://github.com/nebari-dev/nebari/blob/42999695a732056517e475e7627d401a9aa051ae/src/_nebari/stages/kubernetes_services/template/modules/kubernetes/services/jupyterhub/files/jupyterhub/03-profiles.py#L250-L253
launch user with correct uid/gid https://github.com/nebari-dev/nebari/blob/42999695a732056517e475e7627d401a9aa051ae/src/_nebari/stages/kubernetes_services/template/modules/kubernetes/services/jupyterhub/files/jupyterhub/03-profiles.py#L306-L308

Complications that could maybe be addressed in a separate PR. Would this break things?

argo workflows and launching as same uid/gid as user
dask gateway launching as the same uid/gid as user

iameskild commented 1 year ago

The sync_users function looks great!

I think the larger question of how we manage users and groups is tied into this discussion:

When a user needs viewer only access to a shared folder, what mechanism do we have to achieve this?
- Perhaps it's worth creating a few more roles, such as R/W/X for each new group -- I'm still not sure what the best way to enable finer grain permissions without the new of new groups/roles exploding.
We're moving in the direction of a full linux permission model, would it make sense to go all the way there?
- This still doesn't address the UI problem (besides just perform these actions on the terminal).
- And giving individuals root access to the container (and all the attached volumes) can be very dangerous...

costrouc commented 1 year ago

@iameskild good points. Maybe we take advantage of the group all read permission. This would allow us to have a file

user/group/all
xrw/xrw/xr

I think we need to discuss this one more.

At the end I think this should behave like linux permissoining since this would be the easiest to explain. I think as a default we should use the unix model of when a user creates a file it is user writable and group readable.

Adam-D-Lewis commented 1 week ago

@aktech is this done by your recent permissioning work?

nebari-dev / nebari