Re: [ceph-users] Question about RadosGW subusers
Based on past LTS release dates would predict Luminous much sooner than
that, possibly even in May... http://docs.ceph.com/docs/master/releases/
The docs also say "Spring" http://docs.ceph.com/docs/master/release-notes/
-Ben
On Thu, Apr 13, 2017 at 12:11 PM, <ceph.nov...@habmalnefrage.de> wrote:
> 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" <t...@mailchimp.com>
> An: ceph.nov...@habmalnefrage.de
> Cc: "Trey Palmer" <t...@mailchimp.com>, ceph-us...@ceph.com
> Betreff: Re: [ceph-users] 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.nov...@habmalnefrage.de[mailto:
> 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
>
Re: [ceph-users] Question about RadosGW subusers
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" <t...@mailchimp.com>
An: ceph.nov...@habmalnefrage.de
Cc: "Trey Palmer" <t...@mailchimp.com>, ceph-us...@ceph.com
Betreff: Re: [ceph-users] 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.nov...@habmalnefrage.de[mailto: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[mailto:t...@mailchimp.com]>
An: ceph-us...@ceph.com[mailto: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 subu
Re: [ceph-users] 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.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
Re: [ceph-users] Question about RadosGW subusers
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
[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
