[ceph-users] radosgw, Keystone integration, and the S3 API
florian at citynetwork.eu
Thu Nov 22 05:50:27 PST 2018
On 19/11/2018 16:23, Florian Haas wrote:
> Hi everyone,
> I've recently started a documentation patch to better explain Swift
> compatibility and OpenStack integration for radosgw; a WIP PR is at
> https://github.com/ceph/ceph/pull/25056/. I have, however, run into an
> issue that I would really *like* to document, except I don't know
> whether what I'm seeing is how things are supposed to work. :)
> This is about multi-tenancy in radosgw, in combination with S3
> authentication via Keystone (and EC2-compatible credentials generated
> from OpenStack, as explained in my doc patch). Now, when I enable
> rgw_s3_use_keystone_auth and rgw_keystone_implicit_tenants, then, if I
> create an S3 bucket in radosgw for the first time, naming that bucket
> "foo", the following things happen:
> * I see a user that has been created, and that I can query with
> "radosgw-admin user info", that is named
> (that is, the Keystone tenant/project UUID twice, separated by a $
> character). Its display_name is the name of my tenant.
> * With "radosgw-admin bucket list
> I see a bucket that has been created, and that has been named "foo".
> So far, all is well. If I do this, then I can see an bucket named
> "foo" if I use an S3 client, and I can see a container named "foo",
> with identical content, if I use the Swift API.
> Now, if I enable rgw_swift_account_in_url, and update my Keystone
> object store endpoint to include AUTH_%(tenant_id)s, then using the
> Swift API I can also use public ACLs and temp URLs.
> However, I am stumped trying to to understand how exactly this is meant
> to work with the S3 API.
> So I have two questions:
> (1) What do I have to do to get publicly-readable buckets to work in
> the Keystone-authenticated scenario? Moreover, what is the correct
> path to use, for a non-S3 client like curl or a browser, to access
> an object? It seems that using
> http://host:port/ff569d377ecb4f77875fa1b3f89eb16f:foo/bar works
> for S3 objects with a public ACL set, but if I try to use the same
> approach with a signed object, I get a 403 with
> SignatureDoesNotMatch. It seems like what I have to use for a
> signed object is, instead,
> However, if I do *ask* for a signed object that includes the
> tenant name, as in "s3cmd signurl
> s3://5ed51981f4a8468292bf2c578806ebf:foo/bar +120", then I *can*
> use the same URL format as for public ACL objects. Is this the
> intended behavior? If so, does that mean that an application
> using the S3 API, and access/secret keys from OpenStack-backed
> EC2, should configure always itself to use the "<tenant_id>:"
> prefix to precede the bucket name?
> (2) Do I understand the documentation
> correctly in that whenever one uses multitenancy of any kind in
> radosgw, S3 bucket hostnames can't ever be used? Thus, is it correct
> to say that if a radosgw instance is meant to *only* ever
> authenticate its users against Keystone, where there is always a
> radosgw tenant that is being created, then it's pointless to set
> If anyone could shed a light on the above, I can write up the answer and
> amend the doc patch. Thanks!
OK I *think* I've got this fairly well figured out and I've dropped the
WIP prefix from my doc patch:
As this is a documentation patch, you really don't need to be a radosgw
developer to review it — if there's anything you find unclear or plain
wrong by your experience, please do let me know; I'd much appreciate that.
>  This would be an additional question: why is the project UUID in
> there *twice*? Surely there's a good cause for that, but it presently
> escapes me. http://docs.ceph.com/docs/master/radosgw/multitenancy/ says
> "TBD – don’t forget to explain the function of rgw keystone implicit
> tenants = true" here, which isn't very helpful. :)
Although I've covered that TBD in my patch, the question of why the
tenant name is duplicated in the radosgw user name is something I still
haven't been able to suss out. So if anyone can enlighten me there,
that'd be excellent too. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the ceph-users