[openstack-dev] [Keystone] Admin or certain roles should be able to list full project subtree
adriant at catalyst.net.nz
Tue Mar 14 03:24:04 UTC 2017
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
Anyone with some insight into this and is there any interest in making
subtree listing more flexible/useful?
More information about the OpenStack-dev