> 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. 

OpenStack-dev mailing list

Reply via email to