> On Dec 12, 2014, at 10:30, Joe Gordon <joe.gord...@gmail.com> wrote: > > > >> On Fri, Dec 12, 2014 at 6:50 AM, Russell Bryant <rbry...@redhat.com> wrote: >> On 12/11/2014 12:55 PM, Andrew Laski wrote: >> > Cells can handle a single API on top of globally distributed DCs. I >> > have spoken with a group that is doing exactly that. But it requires >> > that the API is a trusted part of the OpenStack deployments in those >> > distributed DCs. >> >> And the way the rest of the components fit into that scenario is far >> from clear to me. Do you consider this more of a "if you can make it >> work, good for you", or something we should aim to be more generally >> supported over time? Personally, I see the globally distributed >> OpenStack under a single API case much more complex, and worth >> considering out of scope for the short to medium term, at least. >> >> For me, this discussion boils down to ... >> >> 1) Do we consider these use cases in scope at all? >> >> 2) If we consider it in scope, is it enough of a priority to warrant a >> cross-OpenStack push in the near term to work on it? >> >> 3) If yes to #2, how would we do it? Cascading, or something built >> around cells? >> >> I haven't worried about #3 much, because I consider #2 or maybe even #1 >> to be a show stopper here. > > Agreed
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. 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. 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? 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. Thanks, Morgan
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
