Hello, Morgan,

The keystone is global service for cascading OpenStack and cascaded OpenStacks, 
just like it works for multi-region. PKI token/UUID token should be workable 
for multi-region first, if there is some security issues, we need to fix it, no 
matter cascading introduced or not.

Using global KeyStone makes the project ID/user/role/domain/group have 
consistentent view in the cloud. The token used in the request to cascading 
Nova/Cinder/Neutron will be transfered in the request to the cascaded 
Nova/Cinder/Neutron too.

Best regards

Chaoyi Huang ( joehuang )

From: Morgan Fainberg [morgan.fainb...@gmail.com]
Sent: 13 December 2014 19:42
To: Henry; OpenStack Development Mailing List (not for usage questions)
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells �C summit 
recap and move forward

On December 13, 2014 at 3:26:34 AM, Henry 
(henry4...@gmail.com<mailto:henry4...@gmail.com>) wrote:
Hi Morgan,

A good question about keystone.

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.

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 

So I have to direct questions:

* 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?

* 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?

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.


Best regards

Sent from my iPad

On 2014-12-13, at 下午3:12, Morgan Fainberg 
<morgan.fainb...@gmail.com<mailto:morgan.fainb...@gmail.com>> wrote:

On Dec 12, 2014, at 10:30, Joe Gordon 
<joe.gord...@gmail.com<mailto:joe.gord...@gmail.com>> wrote:

On Fri, Dec 12, 2014 at 6:50 AM, Russell Bryant 
<rbry...@redhat.com<mailto: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.


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
OpenStack-dev mailing list
OpenStack-dev mailing list

Reply via email to