On Thu, Mar 16, 2017 at 2:46 PM, Morgan Fainberg <morgan.fainb...@gmail.com> wrote:
> > > 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. > > Liked the comparison here, with this in mind, we can try to improve the design of the current solution. > 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 > > -- Rodrigo Duarte Sousa Senior Quality Engineer @ Red Hat MSc in Computer Science http://rodrigods.com
__________________________________________________________________________ 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