[Pulp-dev] When to declare Pulp safe for multi-user?

[Brian Bouterse]

I am in favor of the idea to declare plugins one-by-one as they can be.
Also +1 to adding the column on the plugin list on pulpproject.org here
<https://pulpproject.org/content-plugins/#pulp-3-content-plugins-information>.
I like these ideas better than what I suggested because it doesn't push
plugins to rush-to-implement rbac yet allows pulpcore and pulp_file to go
ahead and do so with 3.7. Please share if there are additional thoughts and
concerns, but the working plan I'm perceiving right now for 3.7 is to:

* enable rbac for pulpcore endpoints - I started an epic for all of these
https://pulp.plan.io/issues/7338 This is not complete, but give us an idea
of where we're going. I will add to this epic and discuss before work
begins.
* enable django-admin more widely for managing object level permissions. It
will also be able to view all objects, but not modify or add model data
(which would bypass the DRF serializers). This will come with this PR
https://github.com/pulp/pulpcore/pull/838 and goes with this issue
https://pulp.plan.io/issues/7336
* enable rbac for pulp_file endpoints - I stubbed out this epic here, I'll
be adding to it https://pulp.plan.io/issues/7339
* declare pulpcore itself multi-user safe, along with a new column on the
plugins list page - https://pulp.plan.io/issues/7309

More feedback, ideas, and concerns are welcome.

On Wed, Aug 12, 2020 at 7:32 AM Tatiana Tereshchenko <ttereshc at redhat.com>
wrote:

>
>
> On Wed, Aug 12, 2020 at 12:34 PM Ina Panova <ipanova at redhat.com> wrote:
>
>>
>>
>>
>> --------
>> Regards,
>>
>> Ina Panova
>> Senior Software Engineer| Pulp| Red Hat Inc.
>>
>> "Do not go where the path may lead,
>>  go instead where there is no path and leave a trail."
>>
>>
>> On Tue, Aug 11, 2020 at 11:10 PM Brian Bouterse <bmbouter at redhat.com>
>> wrote:
>>
>>> Pulpcore 3.6 adds RBAC machinery for plugins to enable RBAC with [0],
>>> but that hasn't happened broadly in plugins or pulpcore yet, so Pulp 3.6 is
>>> still not multi-user safe. I want us to discuss options and strategy for
>>> when can we declare Pulp multi-user safe.
>>>
>>> My take is that, I think we should avoid a situation where no part of
>>> Pulp can be declared multi-user safe until every call in Pulp everywhere is
>>> multi-user safe. I think doing it plugin-by-plugin is a reasonable
>>> middle-ground. Alternatives to consider here would be great.
>>>
>>
>> It might get tricky if we follow that path. I am not sure we can speak
>> for all the plugins, especially the community plugins plans and timelines.
>> What about finding a middle ground and targeting " Pulpcore is multi-user
>> safe 3.7+ with the following list of plugins", where the list will of
>> plugins will be increasing with time.
>> I would not want to hit the bottleneck and wait with "Pulp is multi-user
>> safe unless all plugins have rbac support".
>>
>
> +1, maybe it's worth adding a new column to our plugin table, "multi-user
> safe" - yes/no.
>
>
>>
>>
>>> Assuming a plugin-by-plugin approach, I'd like to propose a few things
>>> for discussion:
>>>
>>> * pulpcore and pulp_file enable RBAC on all of their endpoints for 3.7
>>> * pulpcore declare itself safe for multi-user use for 3.7 [1]
>>> * all plugins discuss-and-communicate which release is their target to
>>> add RBAC support
>>>
>>> +1
>>
> +1
>
>
>>
>> What do you think?
>>>
>>> [0]:
>>> https://github.com/pulp/pulpcore/tree/master/docs/plugins/plugin-writer/concepts/rbac
>>> [1]: https://pulp.plan.io/issues/7309
>>>
>>> -Brian
>>>
>>>
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200818/687abdfc/attachment.htm>