[META] Permissions overhaul

[aktech]

Context

This is a meta issue to define and document problems with the current permissions model in Nebari

Nebari Permissions

🛡️Authentication

Login / Logout to Services or Components

Application	Authentication Required?	Login Behavior	Logout Behavior
Keycloak	Yes	-	-
Monitoring	Yes	Logs in automatically if logged in to Nebari	Nebari Home logout doesn't logs you out of Monitoring
VSCode / JupyterLab	Yes	Logs in automatically if logged in to Nebari	Nebari Home logout logs you out of VSCode/JupyterLab
conda-store	Yes	Requires another login (via Keycloak)	Redirects to localhost after logout, no actual logout (conda-store bug?)
Argo	Yes	Requires another login (via Keycloak)	Nebari Home logout doesn't logs you out of Argo
Dask Diagnostics Dashboard	No (Accessible without auth)	N/A	N/A
Extenstions (e.g. mlflow)	don't care yet	don't care yet	don't care yet

🛡️Authorization

Permission Profiles (JupyterLab Profiles)

profiles:
  jupyterlab:
    - display_name: Small Instance
      description: Stable environment with 1 cpu / 1 GB ram
      access: all
      default: true
      kubespawner_override:
        cpu_limit: 1
        cpu_guarantee: 1
        mem_limit: 1G
        mem_guarantee: 1G
    - display_name: Medium Instance
    ...

• It is possible to control which users have access to which JupyterLab profiles. Each profile has a field named access which can be set to all (default if omitted), yaml, or keycloak.
• all means every user will have access to the profile (default).
• keycloak means that access is restricted to any user who in Keycloak has either their group(s) or user with the attribute jupyterlab_profiles containing this profile name. For example, if the user is in a Keycloak group named developers which has an attribute jupyterlab_profiles set to Large Instance, they will have access to the Large Instance profile. To specify multiple profiles for one group (or user) delimit their names using ## - for example, Large Instance##Another Instance.

Permissions via Keycloak

Groups

• analyst
• developer
• admin
• superadmin

This also gives users the access to right groups in the jupyterhub shared filesystem, if a user is in above groups, they will have access to following shared directories in /shared:

drwxrwxrwx  5 0 0 4.0K Jan  4  2023 developer
drwxrwxrwx  2 0 0 4.0K Apr 12  2023 superadmin
drwxrwxrwx 14 0 0 4.0K Sep 26 16:37 quansight
drwxrwxrwx  4 0 0 4.0K Feb 14 12:34 analyst
drwxrwxrwx  2 0 0 4.0K Feb 27 13:37 admin

When a use spins up a JupyterLab server, it fetches the groups the user is in via Keycloak API and mounts those directories for the user.

Roles

Conda Store

• conda_store_developer (e.g. read access to conda-store namespace say “developer”)
• conda_store_admin
• conda_store_superadmin (e.g. full access to conda-store read/write/delete)

JupyterHub

• jupyterhub_developer
• jupyterhub_admin

Argo

• argo_viewer
• argo_developer
• argo_admin

Keycloak

• realm_admin (Keycloak)

Grafana

• grafana_viewer
• grafana_developer
• grafana_admin

Dask

• dask_developer
• dask_admin

References:

• https://www.nebari.dev/docs/how-tos/configuring-keycloak#in-depth-look-at-roles-and-groups
• https://www.nebari.dev/docs/explanations/profile-configuration#jupyterlab-profiles

Problems / Concerns / Questions:

• Inconsistent Authentication, like logging once doesn’t automatically logs you into all the services and logging out doesn’t logs you out of all the services
• Feature: Varied read/write access to certain groups and same for conda environments via conda-store
• How this affects app sharing system?
  • nobody can share apps
  • everybody can share apps
  • some people can share apps
• conda store has new permissions, look into it
  • design for v2: Improvements to the namespace Role Mappings conda-incubator/conda-store#491 (comment)
  • docs for v2 https://github.com/conda-incubator/conda-store/pull/607/files#diff-5f8356bcc617cf766c46c649e9ada30a6801a8b9a6bd74689ad5595bcdf194c9
  • tests for v2 https://github.com/conda-incubator/conda-store/pull/607/files#diff-3451cc474d5698222168f66a293339a6bd296ee2c56f56409866bbae99917a79R770
  • OUT OF DATE: https://conda.store/conda-store/references/auth#authorization-model
• don’t create shared folder for every group
• conda-store:
  • I want to create a group of people who have read access to conda environments in the quansight namespace
  • separately I want to determine a subset of people in that group who has admin access to quansight namespace
  • potentially: conda_store:env!namespace=quansight
• I want to make a shared dir for qs and I want to make it open to everyone
  • • readonly and I want to add subset of people who have read write access to that dir
• Argo Workflows
  • View user’s own resources only
  • View all logs
• Loki
  • View logs of a user’s own resources only
  • View all logs
• Levels of access (potentially)
  • viewer
  • editor
  • admin

Translation of levels of access between Nebari permissions and respective services permission

Role Mapping (just an idea):

jupyterhub-role:create-share=quansight
jupyterhub-role:no-create-share
conda-store-role:env:quansight:read
conda-store-role:env:quansight:write

Value and/or benefit

• Better UX by consistent Authentication
• Better control over access to resources

Anything else?

No response

[aktech]

An RFD has been created for the RBAC implementation: nebari-dev/governance#47

[viniciusdc]

The RFD above has been accepted, and the work referenced in this issue and in the RFD itself has been broken down in the following issues:

• [ENH] - Make JupyterHub use groups and roles from Keycloak #2308
• [ENH] - Parse and load keycloak roles into JupyterHub #2432
• [ENH] - Parse and load keycloak roles into conda-store #2433
• [ENH] - Create shared directory only if group has permissions #2431