Thanks for testing this and giving feedback!
I am trying to understand why is there a difference
There are two “whys”:
- the direct reason is that they have a different ‘role’ (
token
for the default token role, andserver
for the server token) which in turn may have different scopes (they do by default) - the reason those roles differ is that servers don’t usually need much permissions to function, so they’ve been restricted to just what hey need by default.
The relevant part of the rbac docs is the default roles.
and how would I automatically set the JUPYTERHUB_API_TOKEN with the “full” scoped token?
These roles have default scopes, but you can also override them if you want a different collection of scopes assigned to the roles. It sounds like you want the server token to have full permissions of the owning user, which is encapsulated in the inherit
scope:
c.JupyterHub.load_roles = [
{
'name': 'server',
'scopes': ['inherit'],
}
]
This gets the same permissions you would have with 1.x. Depending on what you are using it for, I’d recommend looking at the available scopes and grant explicit permissions for the additional functionality you want instead of automatically assigning full permissions, but that’s up to you for what makes sense in your deployment.
I opened this pr to add some of these details and this example to the docs.
Extra note:
- Tokens issued via the UI are assigned the
token
role, but the REST API the page uses supports assigning arbitrary roles. This is not exposed in the UI yet, so only the default is used when you click the ‘token’ button
EDIT: changed ‘all’ to ‘inherit’, which was the name we ended up releasing with