Open Stack

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:unsubscribe
> 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


>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170316/6b3d46a3/attachment.html>