On Thu, Mar 16, 2017 at 3:42 PM, Lance Bragstad <lbrags...@gmail.com> wrote:
> > On Thu, Mar 16, 2017 at 12: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:unsubscrib >> e >> 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 > I guess we need a new spec to discuss improvements in the "regular" HMT implementation. Once we cover just the "project hierarchy" we can think in improvements for the reseller use case as well. > > >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > 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
