nebari icon indicating copy to clipboard operation
nebari copied to clipboard

[BUG] - Only users in admin group can create environments

Open ericdatakelly opened this issue 2 years ago • 13 comments

Describe the bug

I am unable to create an environment in a shared namespace via Conda Store. Another user on the same deployment of Nebari has the same experience. Our admin says we are in the shared user groups, so we should be able to create envs in those namespaces. I am able to view and use existing shared environments, but I cannot create one.

Screenshot 2023-08-09 at 7 53 41 AM

Expected behavior

I expected to be able to click on the plus symbol in a shared namespace and create an environment.

OS and architecture in which you are running Nebari

AWS

How to Reproduce the problem?

  • log into Nebari
  • click on Environment Management
  • click on user icon to be sure you are logged in
  • expand a shared namespace (e.g., Analyst, Global, etc.)
  • click on the plus symbol (or hover over symbol to see if permission is given or denied like in screenshot above)

Command output

No response

Versions and dependencies used.

Nebari version: v2023.5.2.dev151+gc6941f3d.d20230727

Compute environment

AWS

Integrations

Keycloak, conda-store

Anything else?

No response

ericdatakelly avatar Aug 09 '23 15:08 ericdatakelly

For reference, this is my view on the same deployment. I'm able to create environments.

image

Eric is in analyst, developer, gpu-access and users groups. I am in admin, analyst, gpu-access, and users.

kcpevey avatar Aug 09 '23 15:08 kcpevey

I added @ericdatakelly to the admin group and he is now able to create environments as expected.

kcpevey avatar Aug 09 '23 15:08 kcpevey

@kcpevey Could you please confirm if this Nebari deployment uses the default Keycloak roles set by Nebari? Double-checking because I believe we can update this configuration in Keycloack later if needed, and I'd like to verify that this is a bug in Nebari vs. a case of better documentation. :)

Also, potential ref: https://github.com/nebari-dev/nebari/blob/a4025800a07adf7d433a066fe5cdf00879941e0a/src/_nebari/template/stages/07-kubernetes-services/modules/kubernetes/services/conda-store/server.tf#L57-L62

pavithraes avatar Aug 10 '23 08:08 pavithraes

@pavithraes the configuration matches the default.

kcpevey avatar Aug 10 '23 13:08 kcpevey

I assumed that users in the analyst group only the had view access to the conda-store. It is still bizarre that they have the same role mapping as developer. This will need to be investigated further.

iameskild avatar Aug 14 '23 16:08 iameskild

We might also need to modify how the role_bindings for developer role:

https://github.com/nebari-dev/nebari/blob/aab5f3f17b14fdc1ce164a94fa81fc975eab5a19/src/_nebari/stages/kubernetes_services/template/modules/kubernetes/services/conda-store/config/conda_store_config.py#L123-L127

iameskild avatar Sep 14 '23 15:09 iameskild

Ref to conda-store role mapping:

Screenshot 2023-09-14 at 9 14 16 PM

pavithraes avatar Sep 14 '23 15:09 pavithraes

Next steps for @fangchenli:

  • Fix the main bug here, i.e., get the "conda_store_developer" which has edit privileges working
  • Scope the new design for analyst/developer/admin groups and roles & look into https://github.com/nebari-dev/nebari/issues/1333

pavithraes avatar Sep 14 '23 16:09 pavithraes

We might also need to modify how the role_bindings for developer role:

https://github.com/nebari-dev/nebari/blob/aab5f3f17b14fdc1ce164a94fa81fc975eab5a19/src/_nebari/stages/kubernetes_services/template/modules/kubernetes/services/conda-store/config/conda_store_config.py#L123-L127

The output for role_bindings looks correct to me. I moved role bindings related code to one method, and here is a simple test.

user = "JohnDoe"
default_namespace = "default"
roles = {"developer"}
groups = {"group1", "group2", "group3"}
role_bindings = create_role_bindings(user, default_namespace, roles, groups)

result:

{'JohnDoe/*': {'admin'}, 'default/*': {'viewer'}, 'global/*': {'developer'}, 'group3/*': {'developer'}, 'group1/*': {'developer'}, 'group2/*': {'developer'}}

fangchenli avatar Sep 15 '23 21:09 fangchenli

This has been resolved at the conda-store level. Nebari needs to be upgraded to V2 role mapping to resolve this issue.

kcpevey avatar Jan 09 '24 17:01 kcpevey

I've verified that this is still an issue. As Kim said above, this can be resolved by upgrading to v2 of conda-store API.

pavithraes avatar Feb 08 '24 15:02 pavithraes

xref: #2090

pavithraes avatar Feb 16 '24 14:02 pavithraes

This will be taken care of as part of the permissions overhaul. Blocked until that work is further along.
xref: https://github.com/nebari-dev/governance/issues/47

kcpevey avatar May 06 '24 16:05 kcpevey

This is resolved by the permissions overhaul.

Keycloak admins can assign fine-grained permissions for certain namespaces with view, edit admin access

https://www.nebari.dev/docs/how-tos/fine-grained-permissions#conda-store-scopes

kcpevey avatar Jul 19 '24 14:07 kcpevey