<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>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.<br>
<br>
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.</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<div class="moz-cite-prefix">On 15/03/17 03:27, Rodrigo Duarte
wrote:<br>
</div>
<blockquote
cite="mid:CAAJsUK+B_OT_6nXPSeBqY1itjQLWyR-R42fkUv-vJrMC8XeO-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Tue, Mar 14, 2017 at 10:36 AM,
Lance Bragstad <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:lbragstad@gmail.com"
target="_blank">lbragstad@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Rodrigo,
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<div><br>
</div>
<div>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. </div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div><br>
</div>
<div>[0] <a moz-do-not-send="true"
href="http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html"
target="_blank">http://specs.openstack.<wbr>org/openstack/keystone-specs/<wbr>specs/keystone/mitaka/<wbr>reseller.html</a></div>
</div>
<div class="gmail-HOEnZb">
<div class="gmail-h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Mar 14, 2017 at
7:38 AM, Rodrigo Duarte <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:rodrigodsousa@gmail.com"
target="_blank">rodrigodsousa@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hi Adrian,
<div>
<div><br
class="gmail-m_-7192138122785756132m_6100159448827737811m_8919781800749074352gmail-Apple-interchange-newline">
In project hierarchies, it is not that
simple to have a "tree admin". Imagine you
have something like the following:</div>
<div><br>
</div>
<div>A -> B -> C</div>
<div><br>
</div>
<div>You are an admin of project C and want
to create a project called "secret_D"
under C:</div>
<div><br>
</div>
<div>A -> B -> C -> secret_D</div>
<div><br>
</div>
<div>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.</div>
</div>
<div><br>
</div>
<div>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 :)</div>
<div class="gmail_extra">
<div>
<div
class="gmail-m_-7192138122785756132h5"><br>
<div class="gmail_quote">On Tue, Mar 14,
2017 at 12:24 AM, Adrian Turjak <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:adriant@catalyst.net.nz"
target="_blank">adriant@catalyst.net.nz</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Hello
Keystone Devs,<br>
<br>
I've been playing with subtrees in
Keystone for the last while, and one<br>
thing that hit me recently is that
as admin, I still can't actually do<br>
subtree_as_list unless I have a role
in all projects in the subtree.<br>
This is kind of silly.</blockquote>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
I can understand why this limitation
was implemented, but it's also a<br>
frustrating constraint because as an
admin, I have the power to add<br>
myself to all these projects anyway,
why then can't I just list them?</blockquote>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
Right now if I want to get a list of
all the subtree projects I need to<br>
do subtree_as_ids, then list ALL
projects, and then go through that
list<br>
grabbing out only the projects I
want. This is a pointless set of<br>
actions, and having to get the full
project list when I just need a<br>
small subset is really wasteful.</blockquote>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
Beyond the admin case, people may in
fact want certain roles to be able<br>
to see the full subtree regardless
of access. In fact I have a role<br>
'project_admin' which allows you to
edit your own roles within the scope<br>
of your project, including set those
roles to inherit down, and create<br>
subprojects. If you have the
project_admin role, it would make
sense to<br>
see the full subtree regardless of
your actually having access to each<br>
element in the subtree or not.<br>
<br>
Looking at the code in Keystone, I'm
not entirely sure there is a good<br>
way to set role based policy for
this given how it was setup. Another<br>
option might be to introduce a
filter which allows listing of<br>
subprojects. Project list is already
an admin/cloud_admin only command<br>
so there is no need to limit it, and
the filter could be as simple as<br>
'subtree=<project_id>' and
would make getting subtrees as
admin, or a<br>
given admin-like role, actually
doable without the pain of roles
everywhere.<br>
<br>
The HMT stuff in Keystone is very
interesting, and potentially very<br>
useful, but it also feels like so
many of the features are a little<br>
half-baked. :(<br>
<br>
Anyone with some insight into this
and is there any interest in making<br>
subtree listing more
flexible/useful?<br>
<br>
Cheers,<br>
Adrian Turjak<br>
<br>
<br>
Further reading:<br>
<a moz-do-not-send="true"
href="https://github.com/openstack/keystone-specs/blob/master/specs/keystone/kilo/project-hierarchy-retrieval.rst"
rel="noreferrer" target="_blank">https://github.com/openstack/k<wbr>eystone-specs/blob/master/spec<wbr>s/keystone/kilo/project-hierar<wbr>chy-retrieval.rst</a><br>
<a moz-do-not-send="true"
href="https://bugs.launchpad.net/keystone/+bug/1434916"
rel="noreferrer" target="_blank">https://bugs.launchpad.net/key<wbr>stone/+bug/1434916</a><br>
<a moz-do-not-send="true"
href="https://review.openstack.org/#/c/167231"
rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/167231</a><br>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List
(not for usage questions)<br>
Unsubscribe: <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
</div>
</div>
<span
class="gmail-m_-7192138122785756132HOEnZb"><font
color="#888888">-- <br>
<div
class="gmail-m_-7192138122785756132m_6100159448827737811m_8919781800749074352gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr"><font
color="#666666">Rodrigo
Duarte Sousa<br>
</font></div>
<div><font
color="#666666">Senior
Quality Engineer @
Red Hat<br>
</font></div>
<div dir="ltr">
<div>
<div><span
style="color:rgb(102,102,102)">MSc</span><span
style="color:rgb(102,102,102)"></span><span
style="color:rgb(102,102,102)"> in
Computer
Science</span><br>
<font
color="#3333ff"><a
moz-do-not-send="true" href="http://rodrigods.com" target="_blank">http://<font
color="#3333ff">rodrigods.com</font></a></font></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</font></span></div>
</div>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for
usage questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr"><font color="#666666">Rodrigo
Duarte Sousa<br>
</font></div>
<div><font color="#666666">Senior Quality
Engineer @ Red Hat<br>
</font></div>
<div dir="ltr">
<div>
<div><span
style="color:rgb(102,102,102)">MSc</span><span
style="color:rgb(102,102,102)"></span><span
style="color:rgb(102,102,102)"> in
Computer Science</span><br>
<font color="#3333ff"><a
moz-do-not-send="true"
href="http://rodrigods.com"
target="_blank">http://<font
color="#3333ff">rodrigods.com</font></a></font></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>