Open Stack

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