My goal is to enable users to share access to their servers (ideally, access and start/stop permissions) by profile rather than every server (“server with arbitrary profile”).
For example, collaborators should be allowed to start my server, but only with a specific profile.
I’m aware that JupyterHub recently introduced sharing access to servers via code. However, this grants access to the server independent of the running profile. I think that named servers would be an elegant solution to this, but we don’t want to allow users to run multiple servers at once.
A simple solution would be to assign scopes to users dynamically via REST API, but according to the docs, this feature is not yet implemented.
Do you have any other approaches (e.g., via hooks or configuration options) in mind that I’m currently missing?
You can limit number of named servers to 1 using c.JupyterHub.named_server_limit_per_user = 1. Note that this config parameter can take a callable function as well in case if you need more fine grained control on number of named servers. At the same time you will have to “disable” default server (the one without name) and this can be done using a custom spawner (This can be done easily by overriding start method of spawner and check if self.name empty or not). Does that work for your use case?
It does not quite solve my problem because it does not limit the access to a certain profile.
So, for instance, I want to add users to my server, but only if I’m running a certain profile (e.g., a profile for group exercises). If I select another profile (e.g., a profile that mounts private data), the collaborators shouldn’t have access to it.
If you have “pre-defined” profiles, you can run the single user servers for these profiles as JupyterHub services and you can use RBAC to give access to different users and/or groups for these services. And users will use regular spawner based single user servers for the ones that are private and should not be shared. But these services are running all the time and there is no notion of starting and stopping them (except by JupyterHub admin).
This isn’t exactly what you want, but you can create collaboration accounts. If you want the collaboration user to have access to the resources of an actual user (e.g. volumes), you’d have to manage that mapping.
I think @mahendrapaipuri 's suggestion of a custom spawner is still valid. Your custom code would check for certain conditions and then return an unauthorized status when needed.
Thus, I use the following setup to share access to servers running a particular profile (if someone is interested).
I have a custom JupyterHub service that allows users to add and remove collaborators. Besides storing this information in a database, revoking a user triggers PATCH /shares/{owner}/ to revoke the shared access. Remember that I cannot grant access during the addition of collaborators because the access should be limited to a profile.
To grant permission, the service provides an additional endpoint, namely GET /share?user={owner}. If a collaborator opens the link, the service checks whether the user is really a collaborator (database lookup) and if a server is running with the allowed profile. Only if that’s the case, access is granted via POST /shares/{owner}
To revoke access for all collaborators after the server is stopped, the post_spawn_hook is used to trigger DELETE /shares/{owner}, which revokes all shared access.