[openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift
guang.yee at hp.com
Wed Jan 9 19:14:47 UTC 2013
Yes. Swift ACLs <tenant_id>:<user_name>, <tenant_id>:<user_name>, and
*:<user_name> will be impacted if project (formely tenant) name and user
name are no longer globally unique. We'll need to figure out a migration
path before relaxing that constraint.
From: Chuck Thier [mailto:cthier at gmail.com]
Sent: Wednesday, January 09, 2013 10:48 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in
Se responses inline:
On Wed, Jan 9, 2013 at 4:01 AM, Henry Nash <henryn at linux.vnet.ibm.com>
> So there are a couple of issues intertwined in this thread:
> 1) Uniqueness of identifiers in Swift given the keystone Identity v3 api.
> This is the issue of whether Swift uses tenant names (now called project
> names) at all to uniquely identify any objects - if it did, then it would
> need to also consider storing a domain name or id. From the discussion,
> sounds like tenant/project ID is used instead, which (from a uniqueness
> point of view) is fine. A separate issue exists needs to be discussed
> around swift ACLs and whether username potentially becoming unique only
> within a domain will have an impact.
For AuthN, you are correct, in that it only relies on tenant/project
ID. So, nothing has to be changed from that perspective. AuthZ is a
little more tricky. For ACLs with keystone, they are set as
TENANT:USER in any of the following patterns:
*:user_name - that user from any tenant has access
tenant_id:user_name - that user from that tenant id has access
tenant_name:user_name - that user from that tenant name has access
If project_name will not be unique in v3, then the
tenant_name:user_name format may have to be deprecated.
I would be interested to hear from providers that are using keystone
with swift and hear which of the above use cases they are using.
> 2) Given that keystone identity v3 domains are likely to be usually used
> represent an enterprise (or "account holder" in common cloud terminology)
> and contain the collection of projects owned by that enterprise, is it
> important for Swift to have that domain knowledge? Will there be
> either within swift (or more likely layered on top of swift) that need
> information? E.g. How would someone layer a billing engine on top of
> that could collate all the swift containers that were part of one domain?
> Obviously that engine could call keystone with each project_id in turn and
> find the domain_id.....but that sounds pretty inefficient.
As is, containers can already be collated for a given tenant/project
id. The containers for a domain is then an aggregate of the project
ids associated to that domain.
I think the default should be that domains are not mapped in swift. I
believe that this will also be required to facilitate backwards
compatibility, which brings up another interesting question -- Is
there an expectation that people will be able to run keystone auth
v2.0 and v3.0 side by side?
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6186 bytes
Desc: not available
More information about the OpenStack-dev