Gathering Information - how do *you* use Pulp's RBAC?

Community
#1

Hello Pulp Users!

In the course of discussing details around the future of Pulp, a recurring question has been “how useful is Pulp’s RBAC feature?” It’s complicated, requires work when developing new features to make sure they’re handled correctly, requires a certain amount of work from an admin to take advantage of it, and collides…oddly…with Pulp’s content-deduplication.

In pursuit of answering this question - we’d like to ask you, the Pulp user community, to let us know what you think! To that end, we’d love answers to the following questions:

  • Does your Pulp installation have non-admin users?
  • If so - what kinds of access do you allow your non-admin users?
  • Do you create your own RBAC policies, or do you just take advantage of the default policies that come with a Pulp installation?
  • Do you know that you can configure Pulp to not use RBAC?

If you do make use of RBAC, we’d love to hear the specific use-case/problem you solve with it!

Thanks for any input, folks!

1 Like
Katello/Pulp-Community Integration meeting minutes
#2

Currently we are hosting a large scale pulp setup primarily to host and manage RPMs and sync external content, as we want to control how content was managed in a particular way we manage access to pulp and what can be done by our own internal App. This App will will use the PULP API, this app effectively has Admin but controls what a user can do external to pulp. This application hooks into out internal OIDC for auth.

As we are now looking to support Domains and private user repos we may or mayno continue to use this model. If we wanted to allow users direct access to Pulp we would expect something like

  • Users accounts are External Pulp
    • e.g. users held within our internal AD and Pulp supports OIDC/SAML
  • Users would be associated to a auth role (groups) manged outside of Pulp
  • This auth role (group) would then be passed in with the Auth payload
  • Pulp maps the auth role (group) to an domain based RBAC policy we create giving using relevant access

This would be a common pattern for us.

#3

Thanks for the thoughtful reply! To clarify a little - in your future pattern, would each domain have a single domain-admin user?

#4

I would expect multiple users, there would be an single admin role but that role could be assigned to multiple users

#5

For us, we treat Pulp as a backend service for storing and publishing packages. All the authZ/authN happens in our frontend application and so we only have a single Pulp admin user. We explored using Pulp RBAC but it just seemed like we had some really complicated and unique auth use cases (e.g. here) that I don’t think it makes sense for Pulp to handle.

So tl;dr - we don’t use Pulp RBAC.

#6

We operate a large installation of Pulp hosted on console.redhat.com. We could not use the RBAC Pulp provides for two reasons:

  • the users and groups data is all external to our installation. In order to use RBAC for authZ, they have to relate to users that are in the Pulp db. Even if we used the django_ldap to get the users at login-time into Pulp’s db, we would have to have a user login first and then assign them permissions second, which is impractical at the scale of users we interact with.
  • It’s too complicated. We used it originally, and our users kept on running into permissions errors over and over again with no end in sight. Ultimately it’s not how we as service operators perceive it’s difficulty, it’s how the users of our service perceive its difficulty. The feedback we got was “just disable it so we can get on with our work”.

So what do we do today? We wrote a custom authZ middleware which is “domain-level authorization”. One or more users or groups (defined externally to Pulp and declared with an incoming trusted header) can be authorized based on a table we store internally.

This approach accomplishes our needs, specifically:

  • Users and Groups live outside of Pulp
  • AuthN occurs outside of Pulp
  • Authorization is a yes/no at the domain level (it’s simple and effective)
  • Groups can self-manage access in the long-term using the group membership tools already on console.redhat.com

The one thing we’d like to have that we don’t have is finer roles within a domain. For example having some users be able to perform operation X, but not operation Y, etc. To do that though, it comes with the requirement that users can do that using console.redhat.com tools (there is an existing RBAC service where you can define Roles and assign users and groups). So even if Pulp’s RBAC somehow got simpler and didn’t require relations to users/groups inside the Pulp DB, we still couldn’t use it because users expect the console.redhat.com RBAC to be used.

1 Like