Anton, It turns out that Adam Emerson is trying to get bucket policies and roles merged in time for Luminous:
https://github.com/ceph/ceph/pull/14307 Given this, I think we will only be using subusers temporarily as a method to track which human or service did what in which bucket. This seems to us much easier than trying to deal with ACL's without any concept of groups, roles, or policies, in buckets that can often have millions of objects. Here is the general idea: 1. Each bucket has a user ("master user"), but we don't use or issue that set of keys at all. radosgw-admin user create --uid=mybucket --display-name="My Bucket" You can of course have multiple buckets per user but so far for us it has been simple to have one user per bucket, with the username the same as the bucket name. If a human needs access to more than one bucket, we will create multiple subusers for them. That's not convenient, but it's temporary. So what we're doing is effectively making the user into the group, with the subusers being the users, and each user only capable of being in one group. Very suboptimal, but better than the total chaos that would result from giving everyone the same set of keys for a given bucket. 2. For each human user or service/machine user of that bucket, we create subusers. You can do this via: ## full-control ops user radosgw-admin subuser create --uid=mybucket --subuser=mybucket:alice --access=full --gen-access-key --gen-secret --key-type=s3 ## write-only server user radosgw-admin subuser create --uid=mybucket --subuser=mybucket:daemon --access=write --gen-access-key --gen-secret-key --key-type=s3 If you then do a "radosgw-admin metadata get user:mybucket", the JSON output contains the subusers and their keys. 3. Raise the RGW log level in ceph.conf to make an "access key id" line available for each request, which you can then map to a subuser if/when you need to track who did what after the fact. In ceph.conf: debug_rgw = 10/10 This will cause the logs to be VERY verbose, an order of magnitude and some change more verbose than default. We plan to discard most of the logs while feeding them into ElasticSearch. We might not need this much log verbosity once we have policies and are using unique users rather than subusers. Nevertheless, I hope we can eventually reduce the log level of the "access key id" line, as we have a pretty mainstream use case and I'm certain that tracking S3 request users will be required for many organizations for accounting and forensic purposes just as it is for us. -- Trey On Thu, Apr 13, 2017 at 1:29 PM, <ceph.nov...@habmalnefrage.de> wrote: > Hey Trey. > > Sounds great, we were discussing the same kind of requirements and > couldn't agree on/find something "useful"... so THANK YOU for sharing!!! > > It would be great if you could provide some more details or an example how > you configure the "bucket user" and sub-users and all that stuff. > Even more interesting for me, how do the "different ppl or services" > access that buckets/objects afterwards?! I mean via which tools (s3cmd, > boto, cyberduck, mix of some, ...) and are there any ACLs set/in use as > well?! > > (sorry if this all sounds somehow dumb but I'm a just a novice ;) ) > > best > Anton > > > Gesendet: Dienstag, 11. April 2017 um 00:17 Uhr > Von: "Trey Palmer" <t...@mailchimp.com> > An: ceph-us...@ceph.com > Betreff: [ceph-users] Question about RadosGW subusers > > Probably a question for @yehuda : > > > We have fairly strict user accountability requirements. The best way we > have found to meet them with S3 object storage on Ceph is by using RadosGW > subusers. > > If we set up one user per bucket, then set up subusers to provide separate > individual S3 keys and access rights for different people or services using > that bucket, then we can track who did what via access key in the RadosGW > logs (at debug_rgw = 10/10). > > Of course, this is not a documented use case for subusers. I'm wondering > if Yehuda or anyone else could estimate our risk of future incompatibility > if we implement user/key management around subusers in this manner? > > Thanks, > > Trey_______________________________________________ ceph-users mailing > list ceph-users@lists.ceph.com http://lists.ceph.com/ > listinfo.cgi/ceph-users-ceph.com > > >
_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
