Identify appropriate roles for course staff

[ryanlovett]

Summary

In the beginning (of jupyterhub), there were regular users and there were admins. Admins could do everything permitted on the hub, while regular users could only start their own servers. Upon request we would grant some instructors and GSIs the role of admin so that they could launch student servers to access their files or debug their notebooks. Infrastructure staff would have to make sure that those who were granted admin rights for a course were not also students taking a different course on the same hub. One strategy would be to isolate certain courses on their own hubs. We would also have to tell admins not to push the big red "Shutdown Hub" button accidentally.

JupyterHub now has more granular roles. This will let us reign in access while still being able to grant certain users the ability to perform some advanced operations. We could also scope their role so that they can only start/stop servers owned by specific users and groups. This has certain repercussions in RTC where users will need to be able to start/stop servers owned by shared accounts. Additionally, we want to be able to set resource limits in group properties (#4364), but we only want people with the "group property editor" role to be able to do that.

This issue is meant to help us track what roles we think we want to hand out in the post-admin times we can live in.

User Stories

This gives all those with the "teacher" role of bcourse course 123456 the ability to visit the admin page, see just the users in their course, start/stop those servers, and also access the running servers. The group of users in their control would be course::123456 rather than course::123456::enrollment_type::student because course staff will also probably want the same access to other course staff scopes for testing.

{
    "name": "course-123456-teacher-role",
    "description": "Give course 123456 staff elevated privileges",
    "scopes": [
        # access to the admin page
        "admin-ui",
        # list users in the class group
        "list:users!group=course::123456",
        # start/stop servers for users in the class
        "admin:servers!group=course::123456",
        # access servers for users in the class
        "access:servers!group=course::123456",
    ],
    "groups": ["course::123456::enrollment-type::teacher"],
}

This gives specific, well trained users the ability to edit the properties of group::123456 under /hub/admin > Manage Groups. This is where they might set resource limits like user server memory.

{
    "name": "course-123456-resource-allocator",
    "description": "Give authorized people the ability to change course::123456 properties",
    "scopes": [
        # access to the admin page
        "admin-ui",
        # list users in the class group
        "list:users!group=course::123456",
        # edit group properties
        "groups!group=course::123456",
    ],
    "users": ["luke.skywalker", "darth.vader"],
}

Such roles could be templated in jupyterhub.hub.extraConfig in hub/values.yml with something like:

15-roles-init:
  all_roles = []
  courses_with_roles = [] # to be overridden by deployments

20-role-templates:
  def course_role_generator(course_id):
      '''Given a course ID, return a role that gives instructors elevated access.'''
      return { "name": f"course-{course_id}-teacher-role", ... }

25-course-role-apply:
  for course_id in courses_with_roles:
    all_roles.append(course_role_generator(course_id))

50-load-roles:
  c.JupyterHub.load_roles(all_roles)

And then in deployment/{deployment}/config/common.yaml there could be:

16-role-template:
  courses_with_roles = ['123456', '234567']

Acceptance criteria

• By defining these roles, course staff will be able to do everything they need to do for their own course, but nothing more.

Important information

This feature requires that users are members of a course according to bcourses. Some students audit courses so aren't formally asociated with the course in SIS. Course staff would need to know how to add those auditors to the course in bcourses.

Additionally, bCourses permits instructors to add all those with the student role to groups. If an instructor wants to add another instructor, ta, or observer to a group, they will need to also add that person to their course as a student. bCourses permits users to be added to the course multiple times with different roles.

Upstream information:

• https://jupyterhub.readthedocs.io/en/latest/rbac/roles.html
• https://jupyterhub.readthedocs.io/en/latest/rbac/scopes.html

Tasks to complete

Work with @balajialg to identify what operations that course staff typically need admin access for. Make sure we map those operations into the appropriate roles.

We might try testing out during Summer loading a role for a course that has traditionally requested admin rights for their course staff.

[balajialg]

@ryanlovett "users": ["luke.skywalker", "darth.vader"] 🥲 🥲

Super excited about testing the bcourses feature during SU 23 as a test run for FA 23. Last year, we just had one-course requesting admin access during summer #3491 and the request came only in July. We can choose a course like Data 8/Data 100/Data 102 and proactively reach out to the instructors to test this feature during the summer. We might have some traction that way!

Going forward, Can you also open this issue in JIRA? It will help from a sprint planning perspective.

[balajialg]

Something unrelated but involves a similar approach in terms of outreach is testing a stable version of JL 4.0 & JN 7.0 (if it release date is as suggested) in one or many interested summer courses. We should validate whether it is ready for a broader rollout in Spring 23