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

Just an update here - first, thanks to everyone who has replied already! This is incredibly useful “real world” data for us. Second, we’re investigating ways we could make Pulp better-able to take advantage of these external authorization models; we’ll keep folk informed as we go, so stay tuned. And third - more data is always welcome! More “how we authorize use of Pulp in our installation” stories would be most appreciated.

1 Like
#8

We had an initial convo with a Red Hatter (Alec Henninger) who is knowledgable on RBAC systems and was able to share some ideas our upstream may be able to use. See the notes here.

In summary, we on the call produced this example of a basic repo, domain, remote schema in SpiceDB. The next step is to build on this example (still in the SpiceDB playground, no code) to identify all of the tuples Pulp would be sending to fulfill this schema along with written use-cases it would fulfill. Additionally, examples of checking AuthZ for each of those use cases can be shown in the spiceDB playground “test relationships” part of the playground.

Anyone can help build out this hackmd document, which is here.

1 Like