[BUG] - Only users in admin group can create environments
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
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.
I added @ericdatakelly to the admin group and he is now able to create environments as expected.
@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 the configuration matches the default.
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.
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
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
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'}}
This has been resolved at the conda-store level. Nebari needs to be upgraded to V2 role mapping to resolve this issue.
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.
xref: #2090
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
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