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

[Rodrigo Duarte]

On Thu, Mar 16, 2017 at 3:42 PM, Lance Bragstad  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"  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

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

[Rodrigo Duarte]

On Thu, Mar 16, 2017 at 2:46 PM, Morgan Fainberg 
wrote:

>
>
> On Mar 16, 2017 07:28, "Jeremy Stanley"  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: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.
>
>
Liked the comparison here, with this in mind, we can try to improve the
design of the current solution.


> TL DR: let's not try and hide projects from users with rights in the same
> (peer, or above) hierarchy.
>

> __
> 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

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

[Lance Bragstad]

On Thu, Mar 16, 2017 at 12:46 PM, Morgan Fainberg  wrote:

>
>
> On Mar 16, 2017 07:28, "Jeremy Stanley"  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: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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 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

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

[Morgan Fainberg]

On Mar 16, 2017 07:28, "Jeremy Stanley"  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: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.
__
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

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

[Jeremy Stanley]

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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Lance Bragstad]

On Thu, Mar 16, 2017 at 8:07 AM, Jeremy Stanley  wrote:

> On 2017-03-15 13:46:42 +1300 (+1300), Adrian Turjak wrote:
> > 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.
> [...]
> > 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.
>
> I have to agree on these points; any attempt to build a feature
> intended to hide resources from the same groups who delegate the
> permission to create them is 1. misguided, and 2. probably entirely
> futile. It will ultimately get treated as a feel-good control with
> no actual teeth, as well as a hindrance to people who end up working
> around it by adding and removing permissions for themselves so they
> can see/manage stuff which would otherwise be hidden from them.
>
> If this makes it in as a supported option, I can't begin to imagine
> the embarrassing security holes you'll end up having to squash all
> over the place where information about "hidden" resources gets
> leaked through side channels in other services (telemetry,
> monitoring, basic math on aggregate quotas, et cetera).
>

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?


> --
> Jeremy Stanley
>
> __
> 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
>
__
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

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

[Jeremy Stanley]

On 2017-03-15 13:46:42 +1300 (+1300), Adrian Turjak wrote:
> 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.
[...]
> 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.

I have to agree on these points; any attempt to build a feature
intended to hide resources from the same groups who delegate the
permission to create them is 1. misguided, and 2. probably entirely
futile. It will ultimately get treated as a feel-good control with
no actual teeth, as well as a hindrance to people who end up working
around it by adding and removing permissions for themselves so they
can see/manage stuff which would otherwise be hidden from them.

If this makes it in as a supported option, I can't begin to imagine
the embarrassing security holes you'll end up having to squash all
over the place where information about "hidden" resources gets
leaked through side channels in other services (telemetry,
monitoring, basic math on aggregate quotas, et cetera).
-- 
Jeremy Stanley

__
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

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

[Adrian Turjak]

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  > 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
> 
> 
>
> On Tue, Mar 14, 2017 at 7:38 AM, Rodrigo Duarte
> > 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
> > 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 

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

[Rodrigo Duarte]

On Tue, Mar 14, 2017 at 10:36 AM, Lance Bragstad 
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
>
> On Tue, Mar 14, 2017 at 7:38 AM, Rodrigo Duarte 
> 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 
>> 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=' 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-requ...@lists.op
>>> enstack.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: 

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

[Lance Bragstad]

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.


[0]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html

On Tue, Mar 14, 2017 at 7:38 AM, Rodrigo Duarte 
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 
> 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=' 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-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>
__
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

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

[Rodrigo Duarte]

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 
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=' 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-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

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

[Adrian Turjak]

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=' 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://bugs.launchpad.net/keystone/+bug/1434916
https://review.openstack.org/#/c/167231



__
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