<div dir="ltr"><div><div>Additional thoughts from working on some non-IT team roles today:<br><br></div>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. <br><br></div>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.<br><br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 15, 2016 at 9:32 PM, Kodiak Firesmith <span dir="ltr"><<a href="mailto:kfiresmith@gmail.com" target="_blank">kfiresmith@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Hi Michael, Pulp Devs,<br><br></div>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.<br><br></div>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. <br><br></div>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.<br><br></div>For user auth, we have set up mod_auth_gssapi and make use of the Apache REMOTE_USER variable (<a href="https://pulp.plan.io/issues/1728" target="_blank">https://pulp.plan.io/issues/1728</a>). Doing this works insomuch as a user can type 'pulp-admin login -u <a href="mailto:kodiak@AD.SOME_COLLEGE.EDU" target="_blank">kodiak@AD.SOME_COLLEGE.EDU</a>', 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:<br><br></div> - 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...)<br></div> TL;DR - going with mod_auth_gssapi is an all-or-nothing proposition and that is not optimal.<br><div> - 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...)<br></div><div> - 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...<br><br></div><div>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:<br><br>Id: content-publisher<br>Display Name: content-publisher<br>Description: Allows content such as RPMs, ISOs, Kickstarts, and other files to<br> be uploaded, assuming the user has additional privileges on the<br> repository they are to be uploaded into<br>Users: <a href="mailto:jim_bob@COLLEGE.EDU" target="_blank">jim_bob@COLLEGE.EDU</a><br>Permissions:<br> /v2/content/repositories/: READ<br> /v2/content/uploads/: READ, CREATE, UPDATE, DELETE<br><br><br>Id: repository-viewer<br>Display Name: repository-viewer<br>Description: Allows user to view all repositories<br>Users: <a href="mailto:jim_bob@COLLEGE.EDU" target="_blank">jim_bob@COLLEGE.EDU</a><br>Permissions:<br> /v2/repositories/: READ<br><br></div><div>I can say from experience this was probably one of the more annoying aspects to cope with as a new user. <br><br></div><div>Anyhow, please let me know if anything needs more explaining - it's kind of a brain dump. <br><br></div><div> - Kodiak Firesmith<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Jul 15, 2016 at 3:29 PM, Michael Hrivnak <span dir="ltr"><<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">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.<div><br></div><div>If we hear silence, we might be more likely to change things, so let us know what is important to you.<br><div><br></div><div><div>Have you integrated Pulp with a separate authentication source? Which one?</div></div><div><br></div><div>Do you assign permissions to specific users? How granular do you need that to be?</div><div><br></div><div>Have you created "roles" in Pulp?</div></div><div><br></div><div>Anything else you want us to know or to think about?</div><div><br></div><div>If you would like to provide input confidentially, you are welcome to contact me directly.</div><div><br></div><div>[0] <a href="https://docs.djangoproject.com/en/1.8/topics/auth/" target="_blank">https://docs.djangoproject.com/en/1.8/topics/auth/</a></div><div><br></div><div>Thank you!</div><span><font color="#888888"><div>Michael</div></font></span></div> <br></div></div>_______________________________________________<br> Pulp-list mailing list<br> <a href="mailto:Pulp-list@redhat.com" target="_blank">Pulp-list@redhat.com</a><br> <a href="https://www.redhat.com/mailman/listinfo/pulp-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-list</a><br></blockquote></div><br></div> </blockquote></div><br></div>