-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ENH] - Implement App permissions/Sharing #11
Comments
REDACTED - The scope of this issue now includes the suggestion from this comment. I've removed it here to keep this issue readable/less confusing. |
To make this a little more clear -
Do we want the ability to control this at the group level as well? Or is that a v2.0 implementation? |
Cross linking previous discussion in #110 I do not see anything about impersonation. Do I correctly assume that users visiting shared apps will still be able to act as the author of the shared app and their activity will be logged as that person (rather as themselves?). My understanding was that using "collaborative users" is required to solve impersonation, but if the proposal in here solves it by itself its even better! |
It's probably not very explicit, as mentioned in the notes above: "All the shared apps, will always be running as the user who created the app."
Yes correct, regarding the activity logging, I am not sure will have be check JupyterHub's sharing docs.
We're not solving impersonation (as in shared notebook apps) yet, as that's beyond the scope. The main use case of app sharing is to share panel, streamlit, bokeh, custom, etc apps and not jupyter notebook server. What we saw in #110 was consequence of #138, the original intention was never to share notebook server/app (even though it is possible to do so by creating a custom jupyter notebook server app and sharing that). When we are sharing panel, streamlit types apps the user with whom the app is shared is actually indeed impersonating in the sense that those apps have access to the original author's data (home directory in Nebari). |
All permissions will be configurable at user as well as group level, made it explicit now. |
As per @dharhas
I was thinking that someone in non-admin group can potentially have permissions (granted explicitly) to share in a group other than the group they are present in, like say
Say superadmin and admin both are able to share apps to people in any group and say developer can have permission to share to people in analyst group. |
Actually, we need to move away from overarching groups like developer, analyst etc. And moves to groups and roles within groups. Let's take an example of a user called Mary. Mary belongs to three groups - Mary has app sharing permission in the When she chooses to share an app she will be able to select any combination of the following.
She should not be able to share with:
From the UI/UX pov, the backend will make available the available groups that can be shared with and probably a way to search for individuals. The exact logic of fetching those lists will be in the backend. |
This is beyond the scope of this ticket, the relevant issue is: nebari-dev/nebari#2304 The groups I mentioned in the example are only for demonstration purpose, not implying them as the ones we're going to have them.
Same, the implementation for this will be proposed in nebari-dev/nebari#2304 Your example seems to be echoing what I said in the above comment (ignore the group names and assume all permissions are explicitly specified as in a group/individual is explicitly given permission to share in a group)
Yes correct, see 4th todo in the "Implementation Steps / Tasks" section in the issue description. |
Feature Description
Fine-grained permissions on the ability to create and share an app.
Possible Permissions
App Sharing
App Creation
Notes:
Implementation Steps / Tasks
This is slightly dependent on: [META] Permissions overhaul nebari#2304
Notes
jhub-apps
isn't supposed to be tightly tied with Nebari, that's why we're using JupyterHub constructs / models to implement everything, for example when not used with Nebari, it would not have keycloak, but it will have users, groups and roles anyway, which means our logic doesn't care about how jhub-apps is deployed. Also, cases where we specifically need to handle a usecase for Nebari, which could be different for a non-kubernetes deployment of jhub-apps we handle that by exposing a configuration option, which can be configured viajupyterhub_config.py
using JAppsConfig, Seeconda_envs
for example, which is set to a function in Nebari, which fetches conda envs from conda-store, but any other deployment of jhub-apps would not need to worry about it.The text was updated successfully, but these errors were encountered: