Open Stack

> On Dec 12, 2014, at 10:30, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> 
> 
> 
>> On Fri, Dec 12, 2014 at 6:50 AM, Russell Bryant <rbryant at 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141212/d2dee349/attachment.html>