Re: Question about RadosGW subusers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks a lot, Trey.

I'll try that stuff next week, once back from Easter holidays.
And some "multi site" and "metasearch" is also still on my to-be-tested list. Need badly to free up some time for all the interesting "future of storage" things.

BTW., we are on Kraken and I'd hope to see more of the new and shiny stuff here soon (something like 11.2.X) instead of waiting for Luminous late 2017. Not sure how the CEPH release policy is usually?!

Anyhow, thanks and happy Easter everyone!
Anton
 

Gesendet: Donnerstag, 13. April 2017 um 20:15 Uhr
Von: "Trey Palmer" <trey@xxxxxxxxxxxxx>
An: ceph.novice@xxxxxxxxxxxxxxxx
Cc: "Trey Palmer" <trey@xxxxxxxxxxxxx>, ceph-users@xxxxxxxx
Betreff: Re:  Question about RadosGW subusers

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.novice@xxxxxxxxxxxxxxxx[mailto:ceph.novice@xxxxxxxxxxxxxxxx]> 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" <trey@xxxxxxxxxxxxx[mailto:trey@xxxxxxxxxxxxx]>
An: ceph-users@xxxxxxxx[mailto:ceph-users@xxxxxxxx]
Betreff:  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@xxxxxxxxxxxxxx[mailto:ceph-users@xxxxxxxxxxxxxx] http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 
 
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com




[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux