Roles in pulpcore

Development
#1

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
#2

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?

#3

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.

#4

Regarding how to have your querysets check permissions, I tried to have the Managers provide that functionality in a centralized way, but it didn’t work out. I’ve concluded whenever your objects is RBAC managed, anytime you are querying it you’ll need to add in the permissions checks there also. I’ve written some background on my experiment here: https://github.com/pulp/pulpcore/pull/1725#issuecomment-984035577

1 Like
#5

In order to manage roles in an effective and delegable way, Pulp will introduce a new “manage roles” permission on RBAC protected models. This will be accompanied by a few nested endpoints that allow the owner of an object to add and remove model role associations to other users and groups.
These new endpoints are certainly also managed by the corresponding access policy, so admins are able to decide upon their fate.

#6

Update: According to the new deprecation policy, removal of the django guardian dependencies has been rescheduled for 3.20.

#7

I’d like us to consider removing the django-admin enabled by default part of pulpcore. We added it to have an easy way for admins to CRUD groups and users, but now we have APIs for all of that. I believe Pulp has way to much relational and huge data to have Django admin be a reasonable UI for it.

I propose we remove it in 3.19. It was tech preview when we added it so removing it is fine.

1 Like
Pulpcore Meeting Minutes
#8

Here’s the issue on the removal of the Django UI served at /pulp/api/v3/admin/.