<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">On December 13, 2014 at 3:26:34 AM, Henry (<a href="mailto:henry4hly@gmail.com">henry4hly@gmail.com</a>) wrote:</div> <blockquote type="cite" class="clean_bq"><span><div bgcolor="#FFFFFF"><div></div><div>
<title></title>
<div>Hi Morgan,</div>
<div><br></div>
<div>A good question about keystone.</div>
<div><br></div>
<div>In fact, keystone is naturally suitable for multi-region
deployment. It has only REST service interface, and PKI based token
greatly reduce the central service workload. So, unlike other
openstack service, it would not be set to cascade mode.</div>
<div><br></div></div></div></span></blockquote><div><br></div><div>I agree that Keystone is suitable for multi-region in some cases, I am still concerned from a security standpoint. The cascade examples all assert a *global* tenant_id / project_id in a lot of comments/documentation. The answer you gave me doesn’t quite address this issue nor the issue of a disparate deployment having a wildly different role-set or security profile. A PKI token is not (as of today) possible to use with a Keystone (or OpenStack deployment) that it didn’t come from. This is like this because Keystone needs to control the AuthZ for it’s local deployment (same design as the keystone-to-keystone federation). </div><div><br></div><div>So I have to direct questions:</div><div><br></div><div>* Is there something specific you expect to happen with the cascading that makes resolving a project_id to something globally unique or am I mis-reading this as part of the design? </div><div><br></div><div>* Does the cascade centralization just ask for Keystone tokens for each of the deployments or is there something else being done? Essentially how does one work with a Nova from cloud XXX and cloud YYY from an authorization standpoint?</div><div><br></div><div>You don’t need to answer these right away, but they are clarification points that need to be thought about as this design moves forward. There are a number of security / authorization questions I can expand on, but the above two are the really big ones to start with. As you scale up (or utilize deployments owned by different providers) it isn’t always possible to replicate the Keystone data around.</div><div><br></div><div>Cheers,</div><div>Morgan</div><br><blockquote type="cite" class="clean_bq"><span><div bgcolor="#FFFFFF"><div>
<div>Best regards</div>
<div>Henry<br>
<br>
Sent from my iPad</div>
<div><br>
On 2014-12-13, at 下午3:12, Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com">morgan.fainberg@gmail.com</a>>
wrote:<br>
<br></div>
<blockquote type="cite">
<div>
<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>
</div>
</blockquote>
<blockquote type="cite">
<div>
<span>_______________________________________________</span><br>
<span>OpenStack-dev mailing list</span><br>
<span><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></span><br>
<span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br>
</div>
</blockquote>
_______________________________________________
<br>OpenStack-dev mailing list
<br>OpenStack-dev@lists.openstack.org
<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<br></div></div></span></blockquote></body></html>