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

Reply via email to