hazza/jupyterhub
1
0
Fork 0
mirror of https://github.com/jupyterhub/jupyterhub.git synced 2025-10-17 15:03:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

Applied text improvement suggestions from code review by @manics

Browse Source 
Co-authored-by: Simon Li <orpheus+devel@gmail.com>
This commit is contained in:
Ivana
2021-02-23 15:05:41 +01:00
committed by GitHub
parent c03ca796ab
commit 5a15fba8b7
3 changed files with 10 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/source/rbac/index.md
View File

@@ -5,7 +5,7 @@ Role Based Access Control (RBAC) in JupyterHub serves to provide finer grained a
## Motivation
The JupyterHub API requires authentication before allowing changes to the administration system. For instance, currently the default behaviour is that creating or deleting users requires *admin rights*. This ensures that an arbitrary user, or even an unauthenticated third party, cannot disrupt the status of the Hub.
This system is functional, but lacks flexibility. If your Hub serves a number of users in different departments, you might want to delegate permissions to other users or automate certain processes. With this framework, appointing a 'group-only admin', or a bot that culls idle servers, requires granting full rights to all actions. This can be error-prone and violates the [principle of least privilige](https://en.wikipedia.org/wiki/Principle_of_least_privilege).
This system is functional, but lacks flexibility. If your Hub serves a number of users in different groups, you might want to delegate permissions to other users or automate certain processes. Appointing a 'group-only admin', or a bot that culls idle servers, requires granting full rights to all actions. This can be error-prone and violates the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege).
To remedy situations like this, we implement an RBAC system. By equipping users, groups and services with *roles* that supply them with a collection of permissions (*scopes*), administrators are able to fine-tune which parties are able to access which resources.

10
docs/source/rbac/roles.md
View File

@@ -9,7 +9,7 @@ JupyterHub provides three **default roles** which are automatically loaded to th
Roles can also be customly defined and assigned to users, services, groups and tokens.
**_Users_** and **_services_** are assigned a default role if no custom role is requested based on their admin status.
**_Users_** and **_services_** are assigned a default role ( **_user_** or **_admin_**) if no custom role is requested based on their admin status.
**_Tokens_**’ roles cannot grant the token higher permissions than their owner’s roles. If no specific role is requested, tokens are assigned the default _user_ role.
@@ -24,7 +24,7 @@ Roles can be defined or modified in the configuration file as a list of dictiona
```python
c.JupyterHub.load_roles = [
 {
   'name': 'Server rights',
   'name': 'server-rights',
   'description': 'Allows parties to start and stop user servers',
   'scopes': ['users:servers', 'read:users:servers'],
   'users': ['alice', 'bob'],
@@ -34,7 +34,11 @@ c.JupyterHub.load_roles = [
 }
]
```
The role `server-rights` now allows the starting and stopping of servers by users `alice` and `bob` and the service `idle-culler`, and any member of the `admin-group` or requests using the tokens `foo-6f6e65`/`bar-74776f` (providing the tokens owner has at least the same permissions).
The role `server-rights` now allows the starting and stopping of servers by any of the following:
- users `alice` and `bob`
- the service `idle-culler`
- any member of the `admin-group`
- requests using the tokens `foo-6f6e65` or `bar-74776f` (providing the tokens owner has at least the same permissions).
Another example:
```python

4
docs/source/rbac/use-cases.md
View File

@@ -93,6 +93,6 @@ c.JupyterHub.load_roles = [
 }
]
```
In the above example, `johan` has privileges inherited from class-A role and the `teacher` role on top of those.
In the above example, `johan` has privileges inherited from `class-A role` and the `teacher` role on top of those.
Note the filters (`!group=`) limiting the priviliges only to the particular groups. `johan` can access the servers and information of `class-B` members only.
Note the filters (`!group=`) limiting the privileges only to the particular groups. `johan` can access the servers and information of `class-B` members only.