<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 2, 2013 at 11:06 AM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi all,<br>
<br>
Looking to start a wider discussion, prompted by:<br>
<a href="https://review.openstack.org/#/c/54651/" target="_blank">https://review.openstack.org/#/c/54651/</a><br>
<a href="https://blueprints.launchpad.net/heat/+spec/management-api" target="_blank">https://blueprints.launchpad.net/heat/+spec/management-api</a><br>
<a href="https://etherpad.openstack.org/p/heat-management-api" target="_blank">https://etherpad.openstack.org/p/heat-management-api</a><br>
<br>
Summary - it has been proposed to add a management API to Heat, similar in<br>
concept to the admin/public API topology used in keystone.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I'm concerned that this may not be a pattern we want to propagate throughout<br>
OpenStack, and that for most services, we should have one API to access data,<br>
with the scope of the data returned/accessible defined by the roles held by<br>
the user (ie making proper use of the RBAC facilities afforded to us via<br>
keystone).<br></blockquote><div><br></div><div>Agree with the concern; Identity API v3 abandons this topology in favor of more granular access controls (policy.json) on a single API.<br></div><div><br></div><div>From an HTTP perspective, API responses should vary according to the token used to access the API. Literally,</div>
<div><br></div><div> Vary: X-Auth-Token</div><div><br></div><div>in HTTP headers.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
In the current PoC patch, a users admin-ness is derived from the fact that<br>
they are accessing a specific endpoint, and that policy did not deny them<br>
access to that endpoint. I think this is wrong, and we should use keystone<br>
roles to decide the scope of the request.<br></blockquote><div><br></div><div>++ (although use of the word "scope" here is dangerous, as I think you mean something different from the usual usage?)</div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
The proposal seems to consider tenants as the top-level of abstraction, with<br>
the next level up being a global service provider admin, but this does not<br>
consider the keystone v3 concept of domains [1]</blockquote><div><br></div><div>v3 also allows domain-level roles to be inherited to all projects owned by that domain, so in effect-- it does (keystone just takes care of it).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">, or that you may wish to<br>
provide some of these admin-ish features to domain-admin users (who will<br>
adminster data accross multiple tenants, just like has been proposed), via the<br>
public-facing API.<br>
<br>
It seems like we need a way of scoping the request (via data in the context),<br>
based on a heirarchy of admin-ness, like:<br>
<br>
1. Normal user<br></blockquote><div><br></div><div>I assume "normal" user has some "non-admin" role on a project/tenant.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2. Tenant Admin (has admin role in a tenant)<br>
3. Domain Admin (has admin role in all tenants in the domain)<br></blockquote><div><br></div><div>As mentioned above, keystone provides a solution to this already that other projects don't need to be aware of.</div><div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
4. Service Admin (has admin role everywhere, like admin_token for keystone)<br></blockquote><div><br></div><div>admin_token is a role-free, identity-free hack. With v3, it's only necessary for bootstrapping keystone if you're not backing to an existing identity store, and can be removed after that.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
The current "is_admin" flag which is being used in the PoC patch won't allow<br>
this granularity of administrative boundaries to be represented, and splitting<br>
admin actions into a separate API will prevent us providing tenant and domain<br>
level admin functionality to customers in a public cloud environment.<br></blockquote><div><br></div><div>"admin" should not be a binary thing -- in the real world it's much more blurry. Users have a finite set of roles/attributes, some of which can be delegated, and those roles/attributes grant the user different sets of capabilities.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
It has been mentioned that in keystone, if you have admin in one tenant, you<br>
are admin everywhere, which is a pattern I think we should not follow<br></blockquote><div><br></div><div>Good! We're working towards eliminating that, but it's been a long, slow road. Deprecating v2 is one next step in that direction. Building a more powerful policy engine is another. Considering identity management as "out of scope"</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
keystone folks, what are your thoughts in terms of roadmap to make role<br>
assignment (at the request level) scoped to tenants rather than globally<br>
applied?</blockquote><div><br></div><div>That's how all role assignments behave today, except for the magical "admin" role in keystone where the scope is completely ignored. Because keystone doesn't manage resources that can are "owned by" tenants/projects like the bulk of OpenStack does (identity management especially).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">E.g what data can we add to move from X-Roles in auth_token, to<br>
expressing roles in multiple tenants and domains?<br></blockquote><div><br></div><div>Tokens can only be scoped to a single project or domain, so that's your mapping. All X-Roles apply to the X-Project or X-Domain in context. I don't think we have a good roadmap to support a single authenticated request with multi-project authorization. The best solution I have is to pass an unscoped token that can be rescoped to two or more projects as needed. Trust-based tokens are explicitly scoped already.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Basically, I'm very concerned that we discuss this, get a clear roadmap which<br>
will work with future keystone admin/role models, and is not a short-term hack<br>
which we won't want to maintain long-term.<br>
<br>
What are peoples thoughts on this?<br>
<br>
[1]: <a href="https://wiki.openstack.org/wiki/Domains" target="_blank">https://wiki.openstack.org/wiki/Domains</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>