[Pulp-dev] Concerns about Users in Pulp3 API

Brian Bouterse bbouters at redhat.com
Thu Feb 7 20:20:38 UTC 2019


Thanks Misa,

The feedback tells me that there are installations that want multiple users
+ RBAC. I think that could be a primary 3.1 feature. Does having RBAC
missing from Pulp 3.0 put it into the "It's not ready for us" category?

To continue discussing removing Users from the Pulp3.0 API, I've not heard
any suggestion not to do that, so I wrote up an issue to remove them to
take us a step closer:  https://pulp.plan.io/issues/4398  Feedback is
welcome!

All the best,
Brian


On Wed, Feb 6, 2019 at 1:33 PM Mihai Ibanescu <mihai.ibanescu at gmail.com>
wrote:

> To describe our use of Pulp 2:
>
> We use roles to limit permissions. We have one user (with its credentials
> baked into automation scripts) that can upload packages to a certain set of
> repositories, but can't publish or change the customer-facing ones.
>
> We have a different user that populates the customer-facing ones.
>
> So a single user scenario is very unhelpful in our deployment.
>
> I agree that, without RBAC, there's not much point in having multiple
> users, but in my case I need both RBAC and multiple users.
>
> With read-only entities (repo versions, publications, etc), keeping track
> of who created them would be a huge bonus. I'd summarize the requirement as
> "audit trail" - good to identify who did what.
>
> To summarize: my use of pulp does not require LDAP integration of any
> sort, because packages are produced by Jenkins jobs calling other Jenkins
> jobs calling the REST API. Others may have different constraints. We are
> fine with a handful of dedicated users, as long as we can limit their
> privileges via roles.
>
> Mihai
>
>
> On Tue, Feb 5, 2019 at 1:18 PM Brian Bouterse <bbouters at redhat.com> wrote:
>
>> I want us to check-in on the User aspects of Pulp 3.0's feature set w.r.t
>> some concerns I have and I've heard echoed on the list before. Overall the
>> only change I'm advocating for is the removal of Users from the API
>> entirely [0] and a shared understanding that Pulp is for single-user
>> environments only (for now). The pulp-manager [1] parts are probably ok
>> as-is.
>>
>> First, Pulp isn't safe to use as a multi-user system because it provide
>> no content isolation. Any user can create falsified packages of any type
>> via Upload and have these packages be used by other users instead of other
>> valid packages that come from trusted remote sources. Think about an
>> impersonation of the rpm providing the 'passwd' binary w/ a slightly
>> modified one. A Pulp system is safe iff a single user, e.g. Katello's user,
>> or a single sysadmin has exclusive control of it.
>>
>> Also, having distinct user identity but no way to authorize and limit
>> what operations a user can take within the Pulp system isn't very usable.
>>
>> Finally, I'm concerned about Pulp having identity management built into
>> its own feature set at all. Identity management can be very complicated.
>> There are whole projects dedicated to it. Users who want "real" identity
>> management I don't believe will choose Pulp's. If third-party ID management
>> is Pulp's recommended approach to having ID management then these User APIs
>> will not be used, maybe by anyone.
>>
>> What do you think?
>>
>> My recommendation is to clearly label Pulp3 as a single-user system and
>> also remove the User parts from the API pre RC. Pulp's API does need
>> protection for its single user, so we could continue to create a single
>> 'admin' User object called like we do now via pulp-manager [1].
>>
>> [0]:
>> https://github.com/pulp/pulp/blob/master/pulpcore/app/viewsets/user.py
>> [1]:
>> https://github.com/pulp/pulp/blob/master/pulpcore/app/management/commands/reset-admin-password.py
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20190207/e1fd3928/attachment.htm>


More information about the Pulp-dev mailing list