Re: s3 bucket policys

[nigel davies <nigdav007@xxxxxxxxx>]

Thanks David and All

I am trying out what you said now.

When talking to my manager about permissions, is it possible to set the sub users with a bucket by bucket permissions, as form your example i would be granting user_a read only permissions on all buckets and user_b would have read write permissions on all buckets?

if this is the case and their is no way to set (with out using policy) to do

bucket_a: user_a=R user_b=RW

bucket_b user_a=RW user_b=R

bucket_c user_a=RW user_b=RW

as i think your example would be

bucket_a: user_a=R user_b=RW

bucket_b user_a=R user_b=RW

bucket_c user_a=R user_b=RW

My bad if i am getting all this wrong or confused. it was all going fine till the permission stuff 

  

On Mon, Nov 6, 2017 at 5:23 PM, David Turner <drakonstein@xxxxxxxxx> wrote:

It's pretty much identical to creating a user with radosgw-admin except instead of user create, you do subuser create.  To create subusers for user_a, you would do something like this...

# read only subuser with the name user_a:read-only

radosgw-admin subuser create --uid=user_a --gen-access-key --gen-secret --subuser=read-only --key-type=s3 --access=read

The --subuser= is a name you give to the subuser to know what it's for.  The --access= is the type of access that subuser will have to this bucket.  Your options are read, write, readwrite, and full.

For our deployment we create buckets with a user and hand out sub-users to people to access the bucket.  Usually it's a full access subuser.  We use the user that created the bucket as an admin user for that bucket and don't pass out the access and secret keys for it.  This is annoying if a project needs to access multiple buckets, because they need to have a new key pair for each bucket.  You also can't set acl permissions for individual objects in the bucket for a subuser.  The permissions for a key pair will apply to everything in a bucket.  It works well enough for what we're doing until we can upgrade to Luminous and take advantage of the newer features for rgw.

On Mon, Nov 6, 2017 at 11:54 AM nigel davies <nigdav007@xxxxxxxxx> wrote:

Thanks all

David if you can explain how to create subusers with keys i happy to try and explain to my boss.

The issue i had with the ACLs, for some reason when i upload a file, to bucket_a with user_a

user_b cant read the file even tho user_b has read permissions on the bucket.

And i tired what Adam said to set the ACLs

 

s3cmd setacl s3://bucket_name --acl-grant=read:someuser
s3cmd setacl s3://bucket_name --acl-grant=write:differentuser 

but has no luck its like the object is locked to that user only, with what ever permissions i set on the bucket it self  

On Mon, Nov 6, 2017 at 4:43 PM, David Turner <drakonstein@xxxxxxxxx> wrote:

If you don't mind juggling multiple access/secret keys, you can use subusers.  Just have 1 user per bucket and create subusers with read, write, etc permissions.  The objects are all owned by the 1 user that created the bucket, and then you pass around the subuser keys to the various apps that need that access to the bucket.  It's not pretty, but it works without altering object permissions.

On Mon, Nov 6, 2017 at 11:38 AM Adam C. Emerson <aemerson@xxxxxxxxxx> wrote:

On 06/11/2017, nigel davies wrote:
> ok i am using Jewel vershion
>
> when i try setting permissions using s3cmd or an php script using s3client
>
> i get the error
>
> <?xml version="1.0"
> encoding="UTF-8"?><Error><Code>InvalidArgument</Code><BucketName>test_bucket</BucketName><RequestId>
> (truncated...)
>    InvalidArgument (client):  - <?xml version="1.0"
> encoding="UTF-8"?><Error><Code>InvalidArgument</Code><BucketName>test_bucket</BucketName><RequestId>tx00000000
>
> 000000000000a-005a005b91-109f-default</RequestId><HostId>109f-default-default</HostId></Error>
>
>
>
> in the log on the s3 server i get
>
> 2017-11-06 12:54:41.987704 7f67a9feb700  0 failed to parse input: {
>     "Version": "2012-10-17",
>     "Statement": [
>         {
>             "Sid": "usr_upload_can_write",
>             "Effect": "Allow",
>             "Principal": {"AWS": ["arn:aws:iam:::user/test"]},
>             "Action": ["s3:ListBucket", "s3:PutObject"],
>             "Resource": ["arn:aws:s3:::test_bucket"]
>         }
> 2017-11-06 12:54:41.988219 7f67a9feb700  1 ====== req done
> req=0x7f67a9fe57e0 op status=-22 http_status=400 ======
>
>
> Any advice on this one

Well! If you upgrade to Luminous the advice I gave you will work
perfectly. Also Luminous has a bunch of awesome, wonderful new
features like Bluestore in it (and really what other enterprise
storage platform promises to color your data such a lovely hue?)

But, if you can't, I think something like:

s3cmd setacl s3://bucket_name --acl_grant=read:someuser
s3cmd setacl s3://bucket_name --acl_grant=write:differentuser

Should work. Other people than I know a lot more about ACLs.

--
Senior Software Engineer           Red Hat Storage, Ann Arbor, MI, US
IRC: Aemerson@OFTC, Actinic@Freenode
0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C  7C12 80F7 544B 90ED BFB9

_______________________________________________
ceph-users mailing list
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