Pete Zaitcev writes: > 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. Ah ok, > >> 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. I was meaning more like when we create users in RGW, we specify the --tenant with whatever keystone uuid was assigned for the user..but I forgot about the the whole keystone-tenant -> rgw-uid mapping thing, so the keystone tenant id is already stored as a RGW user id, we could potentially check the response against the value of uid, but then again creating the user for the first time in RGW will still be sort of a challenge. > 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?). Yeah sure this could also work. > > -- Pete -- Abhishek -- 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
