[Pulp-list] Feedback needed: new user/auth system in 3.0

Tue Jul 19 14:05:30 UTC 2016

Additional thoughts from working on some non-IT team roles today:

It would be super nice if repository paths could be nested in the API
path.  Meaning I could grant permission to /v3/repositories/some_team/,
then the folks in the role with permission would be able to manage their
own repository creation, package upload, deletions etc without each
repository having to be enumerated individually in the role/permission
map.

I can cope with the tedium of managing individual repo permissions at the
outset with for-loops, but the continual maintenance of these permissions
by a pulp super-user rather than delegating to the team that needs the
repos, that's a substantial bottleneck I'd love to see eased in Pulp 3.

On Fri, Jul 15, 2016 at 9:32 PM, Kodiak Firesmith <kfiresmith at gmail.com>
wrote:

> Hi Michael, Pulp Devs,
>
> I'm currently running Pulp independent from Katello/Foreman/Satellite 6
> within a medium sized RHEL infrastructure that uses both Active Directory
> and RADIUS + hardware OTP for authentication in as many services as
> possible.
>
> We serve a mix of Red Hat CDN, third-party, and internal YUM repositories
> to RHEL 5, 6, and 7 clients via emplacement of simple .repo files via
> Puppet.  We don't use Pulp agents on clients now, but I plan to take a hard
> look at what you come up with on that front for Pulp 3.  We would love to
> get package state information of clients via Puppet.
>
> As for pulp-admin access and auth, we allow for scripted processes running
> as root to use /root/.pulp/admin.conf's [auth] section to interact with
> Pulp without having to have an active 'user-cert.pem' file.  I would much
> rather be able to use the host's Kerberos host principal though, as we try
> to do with most rootly interactions needing authentication.
>
> For user auth, we have set up  mod_auth_gssapi and make use of the Apache
> REMOTE_USER variable (https://pulp.plan.io/issues/1728).  Doing this
> works insomuch as a user can type 'pulp-admin login -u
> kodiak at AD.SOME_COLLEGE.EDU', enter their AD password, and obtain a client
> certificate from pulp to grant their continued access for some period of
> time.  There are a number of drawbacks that I'd love to see addressed in
> Pulp 3:
>
>  - Setting up mod_auth_gssapi to authenticate /pulp/api/v2/actions/login
> breaks the ability to use local (non-AD) accounts *at all*, unless they use
> the ~/.pulp/admin.conf[auth], which is inherently insecure as user/passwd
> combos are stored on-disk unencrypted.  (If Pulp at least prompted for
> user/password with each command, we have a way to programmatically pull
> that from an encrypted file via a script but that's getting into the
> weeds...)
>    TL;DR - going with mod_auth_gssapi is an all-or-nothing proposition and
> that is not optimal.
>  - Ideally, you should be able to feed mod_auth_gssapi a Kerberos service
> principal or a TGT; neither of which currently work in Pulp due to the Pulp
> 2.x python code using a library that can't grok it. (sorry can't find the
> abandoned un-merged pull that tries to fix this partially...)
>  - Pulp obviously has no path to 2FA and I can't imagine making it work
> with RADIUS currently and don't know where to start.  But for us users who
> are bound by compliance to use 2FA, we can kind of meet that requirement as
> long as we are obtaining a TGT via 2FA (workstation login for example), so
> if at least we can pass a ticket to Pulp, that solves it for us.  If anyone
> on the Foreman team is snooping this thread, please note we really need 2FA
> / SSO (that doesn't require FreeIPA!) for Satellite 6, hint hint...
>
> Now onto repository roles, I don't have all my thoughts on those composed
> quite yet because I only have a few restricted users on my pulp server so
> far, but I'm getting ready to add a slew soon, so I'll probably have input
> on that in a couple weeks.  Right now I can at least say that it needs MOAR
> DOCs, and it would be super swell if it came with some useful
> pre-configured roles already in the database on new installations, if for
> no other reason to at least give practical examples on what paths are
> necessary for which actions.  I recall having to watch the logs in real
> time with a test account that wasn't a super-user.  Looking at my roles
> right now, I see I've created a couple generic roles I can share without
> spending too much time sanitizing:
>
> Id:            content-publisher
> Display Name:  content-publisher
> Description:   Allows content such as RPMs, ISOs, Kickstarts, and other
> files to
>                be uploaded, assuming the user has additional privileges on
> the
>                repository they are to be uploaded into
> Users:         jim_bob at COLLEGE.EDU
> Permissions:
>   /v2/content/repositories/: READ
>   /v2/content/uploads/:      READ, CREATE, UPDATE, DELETE
>
>
> Id:            repository-viewer
> Display Name:  repository-viewer
> Description:   Allows user to view all repositories
> Users:          jim_bob at COLLEGE.EDU
> Permissions:
>   /v2/repositories/: READ
>
> I can say from experience this was probably one of the more annoying
> aspects to cope with as a new user.
>
> Anyhow, please let me know if anything needs more explaining - it's kind
> of a brain dump.
>
>  - Kodiak Firesmith
>
>
> On Fri, Jul 15, 2016 at 3:29 PM, Michael Hrivnak <mhrivnak at redhat.com>
> wrote:
>
>> As many of you know, we are switching from mongodb to postgres in Pulp
>> 3.0. This will come with quite a few changes. For one in particular, we
>> need your input about how you use Pulp's user and permission system.
>> Anything you can tell us about how you use the current user/perm system
>> would be very helpful. We are considering the use of Django's built-in
>> user/auth system [0] as a replacement for what Pulp currently has.
>>
>> If we hear silence, we might be more likely to change things, so let us
>> know what is important to you.
>>
>> Have you integrated Pulp with a separate authentication source? Which one?
>>
>> Do you assign permissions to specific users? How granular do you need
>> that to be?
>>
>> Have you created "roles" in Pulp?
>>
>> Anything else you want us to know or to think about?
>>
>> If you would like to provide input confidentially, you are welcome to
>> contact me directly.
>>
>> [0] https://docs.djangoproject.com/en/1.8/topics/auth/
>>
>> Thank you!
>> Michael
>>
>> _______________________________________________
>> Pulp-list mailing list
>> Pulp-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-list
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20160719/c9d82352/attachment.htm>