[openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift

David Chadwick d.w.chadwick at kent.ac.uk
Fri Feb 1 11:05:30 UTC 2013


Since the token contains the email address of the user, isnt it possible 
to use this in the ACL?

regards

David

On 23/01/2013 10:23, Alexandra Shulman-Peleg wrote:
> Hi,
>
> I would like to get back to this discussion and specify the exact syntax
> of ACLs that can be used when removing the global uniqueness constraint
> on user names. I wander whether we really need to prefix both the
> project_name and the username with the domain id? Especially, since on
> ACLs we mainly need to properly identify the user and not the project.
> So the notion of a project may not be required in this context? For
> example, in NFSv4 ACLs (also adopted by CDMI) users are identified by
> username at domain. So I wander whether on ACLs, in V3 we can simply switch
> from tenant_id:username to domain_id:username? This seems to fulfill the
> identification requirements and will give a very simple solution for the
> migration of existing v2 customers to private domains in V3 – assigning
> the new domain_id to match the old tenant_id will allow preserving all
> of the stored containers without the need to modify the containers' meta
> data.
>
> Best Regards,
> Alex.
>
>
>
> From: "Yee, Guang" <guang.yee at hp.com>
> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>,
> Date: 11/01/2013 10:31 PM
> Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains
> in Swift
> ------------------------------------------------------------------------
>
>
>
> As long as Swift URL stay the same we should be OK. Frankly, there aren't
> any strong arguments for changing it at this point. Whenever we remove the
> globally uniqueness constraint on names, new Swift ACLs probably will need
> to switch over to using namespacing.
>
> domain_name.project_name:domain_name.username
>
> something like that. Existing Swift ACLs should work fine since if the given
> domain is the default (migrated) system domain, auth_token middleware should
> not set the domains headers.
>
>
> Guang
>
>
> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]
> Sent: Friday, January 11, 2013 8:36 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in
> Swift
>
> Hi Chuck
>
> On 11/01/2013 15:59, Chuck Thier wrote:
>  > The Tenant_ID is in the URL
>  > (https://{SWIFT_IP}/v1/AUTH_{TENANT_ID}/{CONTAINER}/{OBJECT})
>  >
>  > I think we have beaten this part to death a bit now, as we seem to all
>  > agree that we can continue this pattern with the V3 API.  The one
>  > concern that I still have is how the ACLs will work, and weather or
>  > not that will need to change.
>  >
>  > I'm also curious how the Keystone V3 API will work alongside V2 apis.
>
> My opinion (only, I dont speak for anyone else) is as follows:
>
> 1. A v2 API system has no problems as it is working OK today
> 2. A v3 API system only, with domains added, should work OK tomorrow
> otherwise the v3 API has problems
> 3. So the main point as you say is how do v2 and v3 systems interwork. I
> suggest there is an intercept module, say in the Keystone pipeline, that
> knows it is operating in a v2/v3 environment, and when it receives a v2
> request already containing a tenant_ID it knows it will comprise
> domain:project and it can unpack it, and give the separate elements to
> the rest of the V3 code for processing as in a v3 system. When the
> intercept module receives a v2 request that needs a tenant ID returning
> to it, it will encode up the domain and project as a tenant ID, and
> return this to the v2 client. The v2 client will be blissfully unaware
> that what it thinks is a tenant ID is actually a combination of domain
> and project.
>
> regards
>
> david
>
>
>
>  >
>  > --
>  > Chuck
>  >
>  > On Thu, Jan 10, 2013 at 4:16 AM, David Chadwick <d.w.chadwick at kent.ac.uk>
> wrote:
>  >> You have to ask, where does the Swift client get the tenant_Id from?
> Isnt
> it
>  >> Keystone? So if Keystone returns project_ID:tenant_Id to swift as the
>  >> project_id string, then Swift can continue to use this as if nothing has
>  >> changed. Its just a string whose content has no meaning to Swift, but
> whose
>  >> content does have meaning to Keystone. The Swift policy simply needs to
>  >> change the value of the tenant_id in its policy to the new value and it
>  >> should work the same
>  >>
>  >> regards
>  >>
>  >> David
>  >>
>  >>
>  >> On 09/01/2013 20:21, heckj wrote:
>  >>>
>  >>> Given that domains are a segmentation of projects/tenants, then I
> wouldn't
>  >>> expect to want to change it from a project_id representation to
> anything
>  >>> else.
>  >>>
>  >>> -joe
>  >>>
>  >>> On Jan 9, 2013, at 12:13 PM, Chuck Thier <cthier at gmail.com> wrote:
>  >>>>
>  >>>> Things are always easy, until you start thinking about backwards
>  >>>> compatibility.  The storage urls for swift with keystone are currently
>  >>>> keyed off of the tenant_id (soon to be project_id), so you end up with
>  >>>> an endpoint url that looks something like
>  >>>> http://{SWIFT_IP}/v1/AUTH_{TENANT_ID}  if you change that by adding
>  >>>> the domain, then you break any current users in your system, and you
>  >>>> can't use v2 and v3 auth contracts simultaneously.
>  >>>>
>  >>>> --
>  >>>> Chuck
>  >>>>
>  >>>> On Wed, Jan 9, 2013 at 1:37 PM, David Chadwick
> <d.w.chadwick at kent.ac.uk>
>  >>>> wrote:
>  >>>>>
>  >>>>> I would have thought that the solution is conceptually rather
>  >>>>> straightforward. If domains can have their own project names and
>  >>>>> usernames,
>  >>>>> then you prefix the names with the domain ID or domain name to make
> them
>  >>>>> globally unique again.
>  >>>>>
>  >>>>> regards
>  >>>>>
>  >>>>> David
>  >>>>>
>  >>>>>
>  >>>>>
>  >>>>> On 09/01/2013 19:14, Yee, Guang wrote:
>  >>>>>>
>  >>>>>>
>  >>>>>> 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.
>  >>>>>>
>  >>>>>>
>  >>>>>> Guang
>  >>>>>>
>  >>>>>>
>  >>>>>> -----Original Message-----
>  >>>>>> 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
>  >>>>>> Swift
>  >>>>>>
>  >>>>>> Se responses inline:
>  >>>>>>
>  >>>>>> On Wed, Jan 9, 2013 at 4:01 AM, Henry Nash
> <henryn at linux.vnet.ibm.com>
>  >>>>>> wrote:
>  >>>>>>>
>  >>>>>>>
>  >>>>>>> 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,
>  >>>>>>
>  >>>>>>
>  >>>>>> it
>  >>>>>>>
>  >>>>>>>
>  >>>>>>> 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
>  >>>>>>
>  >>>>>>
>  >>>>>> to
>  >>>>>>>
>  >>>>>>>
>  >>>>>>> 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
>  >>>>>>
>  >>>>>>
>  >>>>>> operations
>  >>>>>>>
>  >>>>>>>
>  >>>>>>> either within swift (or more likely layered on top of swift) that
> need
>  >>>>>>
>  >>>>>>
>  >>>>>> that
>  >>>>>>>
>  >>>>>>>
>  >>>>>>> information?  E.g. How would someone layer a billing engine on top
> of
>  >>>>>>
>  >>>>>>
>  >>>>>> swift
>  >>>>>>>
>  >>>>>>>
>  >>>>>>> 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?
>  >>>>>>
>  >>>>>> --
>  >>>>>> Chuck
>  >>>>>>
>  >>>>>> _______________________________________________
>  >>>>>> OpenStack-dev mailing list
>  >>>>>> OpenStack-dev at lists.openstack.org
>  >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>> _______________________________________________
>  >>>>>> OpenStack-dev mailing list
>  >>>>>> OpenStack-dev at lists.openstack.org
>  >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  >>>>>>
>  >>>>>
>  >>>>> _______________________________________________
>  >>>>> OpenStack-dev mailing list
>  >>>>> OpenStack-dev at lists.openstack.org
>  >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  >>>>
>  >>>>
>  >>>> _______________________________________________
>  >>>> OpenStack-dev mailing list
>  >>>> OpenStack-dev at lists.openstack.org
>  >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  >>>
>  >>>
>  >>>
>  >>> _______________________________________________
>  >>> OpenStack-dev mailing list
>  >>> OpenStack-dev at lists.openstack.org
>  >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  >>>
>  >>
>  >> _______________________________________________
>  >> OpenStack-dev mailing list
>  >> OpenStack-dev at lists.openstack.org
>  >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  >
>  > _______________________________________________
>  > OpenStack-dev mailing list
>  > OpenStack-dev at lists.openstack.org
>  > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> [attachment "smime.p7s" deleted by Alexandra Shulman-Peleg/Haifa/IBM]
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list