Determine conda-store access that each Keycloak group should have

[iameskild]

Nebari ships with four default groups each tied to various roles:

• analyst -->conda-store-developer --> see conda-store developer role mapping
  • the default for new users
• developer --> conda-store-developer --> see conda-store developer role mapping
• admin --> conda-store-admin --> see conda-store admin role mapping
• superadmin
  • 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-viewer role to any groups
  • see conda-store viewer role mapping
• Presently only the users in the admin (or superadmin) group can create environments in shared namespaces.
  • Currently to achieve this, we need to either map the conda-store-admin to the developer group or conda-store needs to expand/modify their existing roles.
• 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 global and nebari-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.

[dharhas]

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.

[kcpevey]

The role mapping in conda-store is currently undergoing some improvements which will affect this - https://github.com/conda-incubator/conda-store/issues/491

[kcpevey]

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

[kcpevey]

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.

[kcpevey]

xref: https://github.com/nebari-dev/nebari/issues/2304