On Mar 16, 2017 07:28, "Jeremy Stanley" <fu...@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-requ...@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.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
