Open Stack

See, subdomains I can kind of see working, but the problem I have with
all this in general is that it is kind of silly to try and stop access
down the tree. If you have a role that lets you do 'admin'-like things
at a high point in the tree, you inherently always have access to the
whole tree below you. For standard non-resellers (the common case
really), if you have access at a given project, you probably have access
to everything below you, so 'secret_project_d' is one you have access
to. Not to mention as an 'admin' or some such, you need to know about
'secret_project_d' so that you can confirm the quota it has isn't
stupid, or possibly because you will be paying an invoice for it. Or
because as an admin you need to know that the other people at your
company aren't making crazy project structures below what they should.

Then even for the reseller problem, you need to know about
'secret_project_d' so you can make an invoice for it, because as the
reseller you have to have enough access to bill. Which means pretty much
full access to ceilometer/gnocchi and all the usage data, which will
give you far far more info than the project data in Keystone. In fact,
it kind of feels like we're trying to solve a problem that may not even
be there, or one that is too hard to avoid.

I've always viewed it as, you give someone access to a subtree because
you don't want them to access anything above them, or adjacent subtrees.
No upwards or sideways permission, and that's the power of HMT.
Downwards permission is the way Keystone works so you really can't avoid
it, as anyone who has the power to add their roles downward, or set to
to inherit, will always be able to access and find out about
'secret_project_d', either embrace that, or completely rework Keystone.

Really if you don't want someone to access or know about
'secret_project_d' you make sure 'secret_project_d' is in a totally
unrelated domain from the people you are trying to hide it from.

On 15/03/17 03:27, Rodrigo Duarte wrote:
> On Tue, Mar 14, 2017 at 10:36 AM, Lance Bragstad <lbragstad at gmail.com
> <mailto:lbragstad at gmail.com>> wrote:
>
>     Rodrigo,
>
>     Isn't what you just described the reseller use case [0]? Was that
>     work ever fully finished? I thought I remember having discussions
>     in Tokyo about it.
>
>
> You are right, one of the goals of reseller is to have an even
> stronger separation in the hierarchy by having subdomains, but this is
> not implemented yet. However, I was referring only to the project
> hierarchy and having or not inherited role assignments to grant access
> to the subtree. 
>  
>
>
>
>     [0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html
>     <http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html>
>
>     On Tue, Mar 14, 2017 at 7:38 AM, Rodrigo Duarte
>     <rodrigodsousa at gmail.com <mailto:rodrigodsousa at gmail.com>> wrote:
>
>         Hi Adrian,
>
>         In project hierarchies, it is not that simple to have a "tree
>         admin". Imagine you have something like the following:
>
>         A -> B -> C
>
>         You are an admin of project C and want to create a project
>         called "secret_D" under C:
>
>         A -> B -> C -> secret_D
>
>         This is an example of a hierarchy where the admin of project A
>         is not supposed to "see" the whole tree. Of course we could
>         implement this in a different way, like using a flag "secret"
>         in project "secret_D", but the implementation we chose was the
>         one that made more sense for the way role assignments are
>         organized. For example, we can assign to project A admin an
>         inherited role assignment, which will give access to the whole
>         subtree and make it impossible to create a "secret_D" project
>         like we defined above - it is basically a choice between the
>         possibility to have "hidden" projects or not in the subtree.
>
>         However, we can always improve! Please submit a spec where we
>         will be able to discuss in further detail the options we have
>         to improve the current UX of the HMT feature :)
>
>         On Tue, Mar 14, 2017 at 12:24 AM, Adrian Turjak
>         <adriant at catalyst.net.nz <mailto:adriant at catalyst.net.nz>> wrote:
>
>             Hello Keystone Devs,
>
>             I've been playing with subtrees in Keystone for the last
>             while, and one
>             thing that hit me recently is that as admin, I still can't
>             actually do
>             subtree_as_list unless I have a role in all projects in
>             the subtree.
>             This is kind of silly.
>
>
>             I can understand why this limitation was implemented, but
>             it's also a
>             frustrating constraint because as an admin, I have the
>             power to add
>             myself to all these projects anyway, why then can't I just
>             list them?
>
>
>             Right now if I want to get a list of all the subtree
>             projects I need to
>             do subtree_as_ids, then list ALL projects, and then go
>             through that list
>             grabbing out only the projects I want. This is a pointless
>             set of
>             actions, and having to get the full project list when I
>             just need a
>             small subset is really wasteful.
>
>
>             Beyond the admin case, people may in fact want certain
>             roles to be able
>             to see the full subtree regardless of access. In fact I
>             have a role
>             'project_admin' which allows you to edit your own roles
>             within the scope
>             of your project, including set those roles to inherit
>             down, and create
>             subprojects. If you have the project_admin role, it would
>             make sense to
>             see the full subtree regardless of your actually having
>             access to each
>             element in the subtree or not.
>
>             Looking at the code in Keystone, I'm not entirely sure
>             there is a good
>             way to set role based policy for this given how it was
>             setup. Another
>             option might be to introduce a filter which allows listing of
>             subprojects. Project list is already an admin/cloud_admin
>             only command
>             so there is no need to limit it, and the filter could be
>             as simple as
>             'subtree=<project_id>' and would make getting subtrees as
>             admin, or a
>             given admin-like role, actually doable without the pain of
>             roles everywhere.
>
>             The HMT stuff in Keystone is very interesting, and
>             potentially very
>             useful, but it also feels like so many of the features are
>             a little
>             half-baked. :(
>
>             Anyone with some insight into this and is there any
>             interest in making
>             subtree listing more flexible/useful?
>
>             Cheers,
>             Adrian Turjak
>
>
>             Further reading:
>             https://github.com/openstack/keystone-specs/blob/master/specs/keystone/kilo/project-hierarchy-retrieval.rst
>             <https://github.com/openstack/keystone-specs/blob/master/specs/keystone/kilo/project-hierarchy-retrieval.rst>
>             https://bugs.launchpad.net/keystone/+bug/1434916
>             <https://bugs.launchpad.net/keystone/+bug/1434916>
>             https://review.openstack.org/#/c/167231
>             <https://review.openstack.org/#/c/167231>
>
>
>
>             __________________________________________________________________________
>             OpenStack Development Mailing List (not for usage questions)
>             Unsubscribe:
>             OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>             <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>             http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>             <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 <http://rodrigods.com>
>
>         __________________________________________________________________________
>         OpenStack Development Mailing List (not for usage questions)
>         Unsubscribe:
>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <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 <http://rodrigods.com>
>
>
> __________________________________________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170315/9c90c1b4/attachment.html>