nebari-dev
Determine conda-store access that each Keycloak group should have
Nebari ships with four default groups each tied to various roles:
analyst-->conda-store-developer--> see conda-storedeveloperrole mapping- the default for new users
developer-->conda-store-developer--> see conda-storedeveloperrole mappingadmin-->conda-store-admin--> see conda-storeadminrole mappingsuperadmin- This is a role that we created on the Nebari side that allows them to have effectively full CRUD access on all namespaces/environments.
- It might be better if this was moved to the conda-store project and we just use this new role.
A few things that are worth noting:
- On Nebari, we don't map the
conda-store-viewerrole to any groups - Presently only the users in the
admin(orsuperadmin) group can create environments in shared namespaces.- Currently to achieve this, we need to either map the
conda-store-adminto thedevelopergroup or conda-store needs to expand/modify their existing roles.
- Currently to achieve this, we need to either map the
- At the moment, there is no generic mechanism by which we can grant user A read access on shared namespaces X and Y but full read/write access to namespace Z.
- We can achieve something similar, i.e. we can say all users in the developer group have read/write on all shared folders except for
globalandnebari-git. - Going beyond this might require including additional conda-store roles and then mapping those roles to groups on Keycloak but this would introduce a lot more complex role mapping and is not entirely straightforward.
- We can achieve something similar, i.e. we can say all users in the developer group have read/write on all shared folders except for
We need to move away from using analyst/developer as shortcuts for things.
Really what needs to happen is we have the following roles that can be applied to people or groups (names can change)
- dask: allows a person or a group to use dask
- gpu: allows a person or a group to use gpu instances (this may need to be finer grained, not sure how the instance/group mappings work)
- conda-group-admin - in the short term this should allow you to create/edit environments in any group. Ideally, this is a per group role. i.e. I should be able to be an admin of the data-science group but only a user of say the webdev group.
Another point is I think we might want to change the UI to have another optional section that lets me see and use other peoples personal environments. This might require a flag to decide whether it is enabled.
But I may want to browse to /kcpevey/datascience and look at or use that environment (but not edit). Superadmins can currently do this but since all those environments pollute the root of the conda-store-ui.
The role mapping in conda-store is currently undergoing some improvements which will affect this - https://github.com/conda-incubator/conda-store/issues/491
This is no longer blocked since the latest conda-store release now has the role mapping changes.
This issue covers the same topic as https://github.com/nebari-dev/nebari/issues/1898
We need to revist how groups and roles should be used in general in Nebari.
The analyst/developer/users concept is a leftover from two early use cases that are no longer valid. We have developers which is currently required for dask and we have users which I believe is unused by Nebari but we know of external teams using it.