Add Jupyter hub users without restarting/Directory Authentication

Hi Team,

I am fairly new to JupyterHub. I have two questions.
We have a VM setup in GCP that is currently shared by multiple users.
Is it possible to add users without restarting Jupyterhub services? If yes, can you please point me to resources?

The second question I had is on Authentication. I wanted to integrate our directory to authenticate all JupyterHub users. I saw a Git Authentication which potentially I can use. However, I wanted to make sure that the users don’t see each other notebooks for some security purpose.

Can you please give me some hints on this topic?

Vinay Bagare

The two main choices you have to make when you run JupyterHub are:

  1. which Authenticator do you use and
  2. which Spawner do you use

How you select and configure these determines the answers to you questions.

Is it possible to add users without restarting Jupyterhub services?

The answer to this is ~always yes. JupyterHub generally doesn’t handle creating users, it relies on the chosen Authenticator. If a user is able to login, then.

For example, the default configuration is to use PAMAuthenticator, which may be a good fit for you, since you have an existing system with existing user accounts. That means any user will be able to login with their system password just like they would with SSH, and they will run servers as their actual system user. For this, “adding a user” to JupyterHub is just calling adduser on the system (or any other mechanism for adding a user on the system). You don’t need to tell JupyterHub about it.

When you do need to tell JupyterHub about new users is when you have added configuration to limit which users that can successfully authenticate, but only a subset of those should be allowed (e.g. by setting Authenticator.allowed_users). Any change to JupyterHub’s configuration requires a Hub restart (note that restarting the Hub doesn’t need to interrupt any user sessions).

The second choice is the Spawner. User servers can be in docker containers, systemd units, or simple subprocesses. Again, since you have an existing VM with existing user accounts, the default case of LocalProcessSpawner may be right for you - the user’s server will run as that user in their home directory. So whatever permissions that user has or doesn’t have on the filesystem will be what they have in Jupyter.