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

[ericdatakelly]

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.

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

[kcpevey]

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

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

[kcpevey]

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

[pavithraes]

@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:

nebari/src/_nebari/template/stages/07-kubernetes-services/modules/kubernetes/services/conda-store/server.tf

Lines 57 to 62 in a402580

	role_mapping = {
	"superadmin" = ["conda_store_superadmin"]
	"admin" = ["conda_store_admin"]
	"developer" = ["conda_store_developer"]
	"analyst" = ["conda_store_developer"]
	}

[kcpevey]

@pavithraes the configuration matches the default.

[iameskild]

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]

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

nebari/src/_nebari/stages/kubernetes_services/template/modules/kubernetes/services/conda-store/config/conda_store_config.py

Lines 123 to 127 in aab5f3f

	role_bindings = {
	f"{username}/*": {"admin"},
	f"{default_namespace}/*": {"viewer"},
	"global/*": roles,
	}

[pavithraes]

Ref to conda-store role mapping:

[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 [ENH] - Enable scoped access to specific shared folders #1333

[fangchenli]

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

nebari/src/_nebari/stages/kubernetes_services/template/modules/kubernetes/services/conda-store/config/conda_store_config.py

Lines 123 to 127 in aab5f3f

	role_bindings = {
	f"{username}/*": {"admin"},
	f"{default_namespace}/*": {"viewer"},
	"global/*": roles,
	}

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'}}

[kcpevey]

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

[pavithraes]

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]

xref: #2090

[kcpevey]

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

[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