Roles in pulpcore

Roles in pulpcore

Goals

  • add roles that can be assigned to users or groups of users to transitively grant permissions
  • simplicity - initially can be achieved by restricting role creation to plugin writers
  • make existence of RBAC completely configurable

Implementation

  • role definitions will live in an access policy. a default policy is provided by plugin writers.

Todo to support Implementation

  • refactor queryset restriction get_queryset() function for filtering objects for a specific user
    • TODO: get_objects_for_user() function for filtering objects by permission
  • replace the access policy assignment to not be permission based but instead role-based facilities
    • e.g. replace add_for_users and add_for_groups to not use guardians
  • Remove the django-admin guardian things
    • currently ModelAdmin objects inherit from django-guardian
  • Need to remove the group permission endpoints

Timeline

3.16 - Add all the things
3.17 - remove django guardian from the stack

Future Implementation

  • Add facilities in the API to list roles
  • Add facilities in the API to add global roles to users
  • Add facilities in the API to add global roles to groups
  • Add facilities in the API to add global roles to users for specific objects
  • Add facilities in the API to add global roles to groups for specific objects

Note: users would not be able to do these operations ^ at a “permission” level

Use cases

  • Access policy is only created/updated before anything exists in Pulp
3 Likes

This is great. There have been cases where we’ve had to use one permission as a proxy for a set of permissions to simplify the user experience. For example, with pulp container, we use the add container namespace permission as a blanket permission to allow to create a bunch of related objects (remotes, distributions, repositories etc.) With roles, this problem goes away entirely.

I am a little worried about the idea of removing Django Guardian. That’s going to require a fairly massive overhaul of the existing RBAC implementation. It will also lead to a lot of complicated migrations. For example if a user has permissions to add namespaces, but not edit existing namespaces, how do we cleanly translate that to a role without creating roles for each individual permission that existed within the framework of django guardian?

A small update may be in place:
The current plan says, that roles are no longer defined inside the access policy. Instead, there will be fixed system roles defined side by side with the default access policy on the viewset. Also admins have a full blown rest interface to manage their own sets of roles.