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

[Kodiak Firesmith]

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/20160715/fc666951/attachment.htm>