[Pulp-dev] Concerns about Users in Pulp3 API

[Mihai Ibanescu]

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/20190206/25c1e84c/attachment.htm>