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