On Fri, 22 Apr 2016 18:32:01 +0200 Abhishek Lekshmanan <abhishek@xxxxxxxx> wrote: > > One problem remains, as you can guess: cross-tenant access while > > authenticated with Keystone. This is simply not implemented. We considered > > a couple of approaches, such as > > - a special syntax, such as backslash "tenant\bucket" > > - a new header "X-RGW-Tenant" > > - a user attribute in Keystone (requires cooperation from Keystone) > > - a separate endpoint in the Keystone catalog, possibly using regions > > > > Thanks for raising this issue. Honestly I gave up on finding an elegant > > solution for now, although tinkering with endpoints seems like a winner. > > I think Radoslaw liked it too. If you have ideas, by all means please > > propose them. > > I might be understanding this wrong, but since endpoints are an admin only > thing (to create), are you suggesting something like a different region > per tenant or so? I suggest having two endpoints: one traditional with /swift/v1 and another with /swift/v1/%(tenant_id)s. The problem here is, client has to be told to use one region or ther other, and the default is the old way. > Doesn't keystone returns the tenantid while authenticating (I could be > wrong), in which case we somehow enforce that the tenant-id for a user > created in rgw[1] if you're using keystone should match the ones used at > openstack and check for the value of tenant-id returned by keystone when > authenticating? I'll have to get back to you on this. When I considered using Keystone tenant IDs, I was going to put dollars into them. It works, but but you have to educate administartors to create users with a specific tenant ID. None of the current tools support this. They always let Keystone to select the ID, and it uses a random UUID. Having them not matching was very useful therefore. An operator just lets Keystone do its thing, then we use the "name" instead of their ID, and use it in RGW as ID (clear as mud, right?). -- Pete -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
