Here's another push to the branch (it includes the following additions): https://github.com/pulp/pulp_file/compare/master...bmbouter:rbac-PoC?expand=1
* A FileRepositoryAccessPolicy which provides RBAC for Repositories (not yet sync) * A new Mixin allowing the two policies to share some common components Next up: * have the pup_file define the fileContentAdmin group programmatically * Extend the FileRepositoryAccessPolicy to restrict sync operations * Write up and organize the PoC into a clear, organized format Also of interest today @ttereshc and I had a great convo asking what to do about potential problems when we use Django groups to be a "role". My write up will address this in more detail than I can go into here. We are also looking at what the django-role-permissions project could offer us: https://django-role-permissions.readthedocs.io/en/stable/utils.html I expect the PoC to be done by tomorrow and write-up by Monday, so I'm going to schedule the public review meeting for next week towards the end of the week. On Wed, Jun 24, 2020 at 5:49 PM Brian Bouterse <bmbou...@redhat.com> wrote: > Moar progress! Today the following things got done: Today's changes are > available here: > https://github.com/pulp/pulp_file/compare/master...bmbouter:rbac-PoC?expand=1 > > * Got scoped querysets working! This restricts list views to only show > objects a user has permissions to view. A db reset was all that was needed > I think I didn't have all the changes in when I applied my earlier > migrations > * Added "detail view" restriction, and while it's in the policy and > working DRF does a strange thing on "retrieve" where if it's not in the > queryset (due to scoping ^) the user receives a 404, not a permission denied > * Got permissions cleaning up on resource deletion now too > > Next up: > * have the pup_file define the fileContentAdmin group programmatically > * Make similar policies for FileRepository which governs itself and the > "sync" action > * Write up and organize the PoC into a clear, organized format > > Questions and feedback are welcome! > > On Tue, Jun 23, 2020 at 5:54 PM Brian Bouterse <bmbou...@redhat.com> > wrote: > >> Lots of progress today! I have a mostly-complete policy for RBAC for >> FileRemote. It's surprising how little code all of this ended up being. >> >> Here's the actual RBAC stuff, it's all in pulp_file: >> https://github.com/pulp/pulp_file/compare/master...bmbouter:rbac-PoC?expand=1 >> Here's the parts that go in core. Note the LDAP stuff is all optional, >> the only real requirement are two lines 1) enabling guardian in >> INSTALLED_APPS and 2) adding it as an AuthenticationBackend: >> https://github.com/pulp/pulpcore/compare/master...bmbouter:rbac-PoC >> >> I have some "how to use notes" here: >> https://hackmd.io/DRqGFyRsSDmN7E4TtOPf-w The idea is that it implements >> the FileRemote portions of this requirements docs: >> https://hackmd.io/kZ1oYp8TTkeuC5KL_ffjGQ >> >> Here is the short list of things for FileRemote that still don't work. >> This is mainly so I remember what to do next. :) >> * The get_objects_for_user >> <https://django-guardian.readthedocs.io/en/latest/api/guardian.shortcuts.html#get-objects-for-user> >> from DjangoGuardian I don't think it likes Master/Detail or maybe it's >> how/where I'm using it. I haven't yet debugged this. For this reason it >> doesn't provide list restriction >> * It still needs "detail view" restriction. This is straightforward. >> * The group should be programmatically defined, in this case it was >> "defined in LDAP". It could *also* live in LDAP (or other external group >> definition system) but the plugin builds permissions off of it so it should >> also define it. This is easy. >> >> Feedback is welcome. I'm going to continue building this and then >> schedule a public review of FileRemote, Content modification for file >> repos, and sync restriction next week. >> >> >> >> On Mon, Jun 22, 2020 at 5:14 PM Brian Bouterse <bmbou...@redhat.com> >> wrote: >> >>> # ldap PoC updates >>> Now users, groups, and group membership are populating from ldap >>> automatically on login (with auth backed by ldap also)! I'll be sharing my >>> configs for both ldap and how to configure django-auth-ldap >>> <https://django-auth-ldap.readthedocs.io/en/latest/example.html> here >>> soon in an organized way. This was done with django-auth-ldap and 0 >>> customization to pulp code. It's 100% enabled through settings so this work >>> is more of an approach we can document for users that they can enable and >>> not a feature Pulp ships itself. >>> >>> # django-admin progress >>> Thanks to @alikins existing PRs, I got django admin enabled and able to >>> view/edit users, groups, group membership, and permissions at both the user >>> and group levels. This is important because this will be the primary >>> mechanism of administrators. This part is looking good. >>> >>> # new resources to help us out >>> Through collaboration with @ttereshc and someone off list named @adelton >>> (who actually authored this reference approach >>> <https://www.adelton.com/django/external-authentication-for-django-projects> >>> I referenced early on in this exploration), this very cool repository of >>> testing tools was identified: https://github.com/adelton/webauthinfra >>> It has a treasure trove of testing containers which Pulp devs in the future >>> can test against. It keeps the user/group check in the apache which is fine >>> alternative to the django-auth-ldap approach above. Pulp doesn't have to >>> choose, it could work with either just configured differently. The pending >>> PoC outline will go over these alternative approaches in detail. >>> >>> # Next Steps: back to the PoC itself >>> Now that we have demonstrated good options of external >>> users/groups/membership loading into Pulp we can confidently move back to >>> finishing the RBAC PoC itself. I've started back into this. So the >>> remaining work are the two steps below: >>> >>> 1. Finish the PoC that uses RBAC to restrict remotes, sync, and >>> repository content modification. Currently I prototyped restriction of >>> operations on Remotes, but I need to replicate the access policies to >>> Repositories and Sync next. >>> 2. Write it up and share it. >>> 3. Schedule public meeting to review it (targeting next-week) >>> >>> >>> >>> On Fri, Jun 19, 2020 at 5:09 PM Brian Bouterse <bmbou...@redhat.com> >>> wrote: >>> >>>> I got the LDAP users both authenticating and importing into Pulp! Next >>>> I'll do the groups and then I think the ldap parts will be done. >>>> >>>> FYI: I'm going to write up the implementation design and have that come >>>> with this proof of concept code . This will let us know what choices it >>>> makes, why it makes them, and we can determine if these are the right >>>> choices together. >>>> >>>> On Wed, Jun 17, 2020 at 4:57 PM Brian Bouterse <bmbou...@redhat.com> >>>> wrote: >>>> >>>>> I got a lot further on this today. I have the test ldap setup with >>>>> several test users and groups. I have django-auth-ldap configured mostly >>>>> authenticating username/password against ldap instead of the internal >>>>> database first. Once that is fully working the users will auto-populate >>>>> into django and the groups should follow easily. >>>>> >>>>> Once that's done I'll be unblocked to finish the RBAC PoC. The rest of >>>>> the parts are straightforward given the testing I've already done. More >>>>> updates to come. >>>>> >>>>> On Mon, Jun 15, 2020 at 5:03 PM Brian Bouterse <bmbou...@redhat.com> >>>>> wrote: >>>>> >>>>>> I got the ldap reference implementation performing auth really nicely >>>>>> against a test ldap with this guide: >>>>>> https://www.nginx.com/blog/nginx-plus-authenticate-users/ Now there >>>>>> are some new challenges though: >>>>>> >>>>>> * Great that we can auth users, but we need nginx to >>>>>> extract-and-forward the group information to Pulp itself. That way a >>>>>> middleware can create the user AND group info in the backend. >>>>>> * we have to figure this out all again in Apache... >>>>>> >>>>>> Maybe we should be integrating Pulp directly against django-auth-ldap >>>>>> [0]. I am going to try that next. The work I've done isn't 100% reusable >>>>>> there, but most of it is because the test server and configs I used can >>>>>> all >>>>>> be reused directly with django-auth-ldap. The concern with this approach >>>>>> is >>>>>> that we would be supporting LDAP (and transitively Active Directory) but >>>>>> are there other directory services Pulp needs to support? >>>>>> >>>>>> I also emailed Bin Li asking for info on how their user and group >>>>>> management works. >>>>>> >>>>>> On Tue, Jun 9, 2020 at 11:48 AM Adrian Likins <alik...@redhat.com> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 5, 2020 at 8:23 PM Brian Bouterse <bmbou...@redhat.com> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> 1) django admin (the built in django UI) will be the mechanism >>>>>>>> administrators use to assign permissions to users and groups. This >>>>>>>> means >>>>>>>> the use of django admin with pulp is very likely (to me). >>>>>>>> >>>>>>>> Hopefully https://github.com/pulp/pulpcore/pull/705 will be useful >>>>>>> here. >>>>>>> >>>>>>> >>>>>>>> 2) externally defined users and groups will need to be "replicated" >>>>>>>> to django's db at login time, probably using headers from the webserver >>>>>>>> This is consistent w/ the approach recommended here: >>>>>>>> https://www.adelton.com/django/external-authentication-for-django-projects >>>>>>>> >>>>>>> >>>>>>> This is more or less what galaxy_ng ends up doing, at least for the >>>>>>> scenarios where it runs hosted with external SSO. >>>>>>> >>>>>>> https://github.com/ansible/galaxy_ng/blob/master/galaxy_ng/app/auth/auth.py#L51 >>>>>>> for >>>>>>> example. >>>>>>> >>>>>>> >>>>>>
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev