[openstack-dev] [Keystone] Admin or certain roles should be able to list full project subtree

Rodrigo Duarte rodrigodsousa at gmail.com
Tue Mar 14 12:38:10 UTC 2017

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>

> 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/spec
> s/keystone/kilo/project-hierarchy-retrieval.rst
> https://bugs.launchpad.net/keystone/+bug/1434916
> 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170314/02072106/attachment.html>

More information about the OpenStack-dev mailing list