<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On Dec 12, 2014, at 10:30, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 12, 2014 at 6:50 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/11/2014 12:55 PM, Andrew Laski wrote:<br>
> Cells can handle a single API on top of globally distributed DCs. I<br>
> have spoken with a group that is doing exactly that. But it requires<br>
> that the API is a trusted part of the OpenStack deployments in those<br>
> distributed DCs.<br>
<br>
</span>And the way the rest of the components fit into that scenario is far<br>
from clear to me. Do you consider this more of a "if you can make it<br>
work, good for you", or something we should aim to be more generally<br>
supported over time? Personally, I see the globally distributed<br>
OpenStack under a single API case much more complex, and worth<br>
considering out of scope for the short to medium term, at least.<br>
<br>
For me, this discussion boils down to ...<br>
<br>
1) Do we consider these use cases in scope at all?<br>
<br>
2) If we consider it in scope, is it enough of a priority to warrant a<br>
cross-OpenStack push in the near term to work on it?<br>
<br>
3) If yes to #2, how would we do it? Cascading, or something built<br>
around cells?<br>
<br>
I haven't worried about #3 much, because I consider #2 or maybe even #1<br>
to be a show stopper here.<br></blockquote><div><br></div><div>Agreed</div></div></div></div></blockquote><br><div>I agree with Russell as well. I also am curious on how identity will work in these cases. As it stands identity provides authoritative information only for the deployment it runs. There is a lot of concern I have from a security standpoint when I start needing to address what the central api can do on the other providers. We have had this discussion a number of times in Keystone, specifically when designing the keystone-to-keystone identity federation, and we came to the conclusion that we needed to ensure that the keystone local to a given cloud is the only source of authoritative authz information. While it may, in some cases, accept authn from a source that is trusted, it still controls the local set of roles and grants. </div><div><br></div><div>Second, we only guarantee that a tenan_id / project_id is unique within a single deployment of keystone (e.g. Shared/replicated backends such as a percona cluster, which cannot be when crossing between differing IAAS deployers/providers). If there is ever a tenant_id conflict (in theory possible with ldap assignment or an unlucky random uuid generation) between installations, you end up with potentially granting access that should not exist to a given user. </div><div><br></div><div>With that in mind, how does Keystone fit into this conversation? What is expected of identity? What would keystone need to actually support to make this a reality?</div><div><br></div><div>I ask because I've only seen information on nova, glance, cinder, and ceilometer in the documentation. Based upon the above information I outlined, I would be concerned with an assumption that identity would "just work" without also being part of this conversation. </div><div><br></div><div>Thanks,</div><div>Morgan </div></body></html>