<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 14, 2013 at 11:43 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"><div class=""><div class="h5">On Thu, Nov 14, 2013 at 10:20:02AM -0600, Dolph Mathews wrote:<br>

> On Sat, Nov 2, 2013 at 11:06 AM, Steven Hardy <<a href="mailto:shardy@redhat.com">shardy@redhat.com</a>> wrote:<br>
><br>
> > 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.<br>
><br>
><br>
> > I'm concerned that this may not be a pattern we want to propagate<br>
> > throughout<br>
> > OpenStack, and that for most services, we should have one API to access<br>
> > 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>
> ><br>
><br>
> Agree with the concern; Identity API v3 abandons this topology in favor of<br>
> more granular access controls (policy.json) on a single API.<br>
><br>
> From an HTTP perspective, API responses should vary according to the token<br>
> used to access the API. Literally,<br>
><br>
>   Vary: X-Auth-Token<br>
><br>
> in HTTP headers.<br>
><br>
><br>
> ><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>
> ><br>
><br>
> ++ (although use of the word "scope" here is dangerous, as I think you mean<br>
> something different from the usual usage?)<br>
<br>
</div></div>I was using "scope" to say the context of the request can affect what data<br>
is returned, ie the filters we apply when processing it.<br>
<div class="im"><br>
> > The proposal seems to consider tenants as the top-level of abstraction,<br>
> > 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]<br>
><br>
><br>
> v3 also allows domain-level roles to be inherited to all projects owned by<br>
> that domain, so in effect-- it does (keystone just takes care of it).<br>
<br>
</div>Ok, thanks, that's useful info<br>
<div class="im"><br>
> > , 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<br>
> > the<br>
> > public-facing API.<br>
> ><br>
> > It seems like we need a way of scoping the request (via data in the<br>
> > context),<br>
> > based on a heirarchy of admin-ness, like:<br>
> ><br>
> > 1. Normal user<br>
> ><br>
><br>
> I assume "normal" user has some "non-admin" role on a project/tenant.<br>
<br>
</div>Yep, that's my assumption, just not a role associated with admin-ness.<br>
<br>
<snip><br>
<div class="im">> > 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>
> ><br>
><br>
> Tokens can only be scoped to a single project or domain, so that's your<br>
> mapping. All X-Roles apply to the X-Project or X-Domain in context. I don't<br>
> think we have a good roadmap to support a single authenticated request with<br>
> multi-project authorization. The best solution I have is to pass an<br>
> unscoped token that can be rescoped to two or more projects as needed.<br>
> Trust-based tokens are explicitly scoped already.<br>
<br>
</div>So this is a piece of the puzzle I was missing until now, combined with the<br>
fact that Domain scoped tokens do not imply authorization with all projects<br>
within that domain.  Thanks for the IRC conversation which cleared that up!<br>
<br>
Based on this revised understanding, it sounds like, for now at least, some<br>
of the global "management api" requirements may be best served via some<br>
client tools which make multiple API calls to get the required information,<br>
on behalf of a user who has the necessary roles to access all the projects.<br></blockquote><div><br></div><div>(we discussed this a bit in IRC, but I wanted to bring this back to the list as well) I'm going to use projects & users sort of interchangeably here depending, so beware... it's a bumpy ride :)</div>
<div><br></div><div>The underlying use case, so far as I can see, is actually a tenant-less request, rather than a multi-tenant request. This is exactly the use case we have in keystone for things like managing the service catalog -- we're not managing the service catalog for a specific tenant (although, I suppose we could), we're managing it for the instance of keystone itself (and ultimately, all users of that cloud). The community has previously discussed "global roles" (roles applicable to all tenants) and expressed opposition -- but I think this concept and use case are very distinct. Hopefully I can explain...</div>
<div><br></div><div>The modern parity for "global roles" is "domain-based role assignments that are inherited to all projects owned by that domain." Which is to say, one role assignment makes a role available in a large collection of project scopes. That's available in keystone as of Havana, and *could* be used by heat here, but requires looping through all projects with a bunch of tokens to get all the data as shardy described. Not fun and probably not appropriate.</div>
<div><br></div><div>I see shardy's use case as being for "tenantless roles," which would fit nicely with "unscoped tokens" (ones that carry neither domain-based nor project-based authorization). It's still a very explicit assignment, and would be consumed by simply not specifying a project / domain during auth.</div>
<div><br></div><div>These roles would therefore not be consumable by users with default_project_ids (those with default tenancy), but I suspect that would be acceptable for the subset of users that need to utilize such role assignments (users that are not consuming openstack resources, but are instead interacting with management API's, etc).</div>
<div><br></div><div>I believe it solves the issue of vague "admin"ness as well, as keystone would then be explicitly looking for a tenantless role assignment for most operations (e.g. create_service, create_domain, etc) -- and therefore use "unscoped tokens." Domain-scoped tokens could then be used for things like create_project and role assignments. I can't think of a use case for keystone to continue consuming project-scoped tokens off the top of my head (?).</div>
<div><br></div><div>Shameless plug- I added this topic to the keystone meeting agenda for next week:</div><div><br></div><div>  <a href="https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting">https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting</a></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>
Thanks,<br>
<br>
Steve<br>
<div class=""><div class="h5"><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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>