Open Stack

On Thu, Mar 16, 2017 at 3:42 PM, Lance Bragstad <lbragstad at gmail.com> wrote:

>
> On Thu, Mar 16, 2017 at 12:46 PM, Morgan Fainberg <
> morgan.fainberg at gmail.com> wrote:
>
>>
>>
>> On Mar 16, 2017 07:28, "Jeremy Stanley" <fungi at yuggoth.org> wrote:
>>
>> On 2017-03-16 08:34:58 -0500 (-0500), Lance Bragstad wrote:
>> [...]
>> > These security-related corner cases have always come up in the past when
>> > we've talked about implementing reseller. Another good example that I
>> > struggle with is what happens when you flip the reseller bit for a
>> project
>> > admin who goes off and creates their own entities but then wants
>> support?
>> > What does the support model look like for the project admin that needs
>> help
>> > in a way that maintains data integrity?
>>
>> It's still entirely unclear to me how giving someone the ability to
>> hide resources you've delegated them access to create in any way
>> enables "reseller" use cases. I can understand the global admins
>> wanting to have optional views where they don't see all the resold
>> hierarchy (for the sake of their own sanity), but why would a
>> down-tree admin have any expectation they could reasonably hide
>> resources they create from those who maintain the overall system?
>>
>> In other multi-tenant software I've used where reseller
>> functionality is present, top-level admins have some means of
>> examining delegated resources and usually even of impersonating
>> their down-tree owners for improved supportability.
>> --
>> Jeremy Stanley
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> Hiding projects is a lot like implementing Mandatory Access Control
>> within OpenStack. I would like to go on record and say we should squash the
>> hidden projects concept (within a single hierarchy). If we want to
>> implement MAC (SELinux equivalent) in OpenStack, we have a much, much,
>> bigger scope to cover than just in Keystone, and this feels outside the
>> scope of any heirarchical multi-tenancy work that has been done/will be
>> done.
>>
>> TL DR: let's not try and hide projects from users with rights in the same
>> (peer, or above) hierarchy.
>>
>
> If that's the direction - we need to realign our documentation [0].
>
>
> [0] http://specs.openstack.org/openstack/keystone-specs/
> specs/keystone/mitaka/reseller.html#problem-description
>

I guess we need a new spec to discuss improvements in the "regular" HMT
implementation. Once we cover just the "project hierarchy" we can think in
improvements for the reseller use case as well.


>
>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170316/2e89ca81/attachment.html>