On Thu, Mar 16, 2017 at 12:46 PM, Morgan Fainberg <[email protected] > wrote:
> > > On Mar 16, 2017 07:28, "Jeremy Stanley" <[email protected]> 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: [email protected]?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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
