On Thu, Oct 05, 2023 at 09:22:29AM +0200, Robert Hish wrote: > Unless I'm misunderstanding your situation, you could also tag your > placement targets. You then tag users with the corresponding tag enabling > them to create new buckets at that placement target. If a user is not tagged > with the corresponding tag they cannot create new buckets at that placement > target. The tags do not prevent users from using buckets that are already > owned/created by them. > > It adds a bit of management overhead, but should give you the control youre > looking for. > > https://docs.ceph.com/en/latest/radosgw/placement/#user-placement thanks. Seems like a bit of work initially configuring placement targets, but perhaps easier to handle when only a few users get to create buckets vs. a large number of users without bucket creation rights. Matthias > > -Robert > > On 10/4/23 19:32, Matthias Ferdinand wrote: > > > Tried a negative number ("--max-buckets=-1"), but that had no effect at > > > all (not even an error message). > > > > must have mistyped the command; trying again with "-max-buckets=-1", it > > shows the wanted effect: user cannot create any bucket. > > > > So, an effective and elegant method indeed :-) > > > > Matthias > > > > PS: answering my own question below "how can I keep users from deleting > > their own bucket?": bucket policy. > > > > $ cat denypolicy.txt > > { > > "Version": "2012-10-17", > > "Statement": [{ > > "Effect": "Deny", > > "Principal": {"AWS": ["*"]}, > > "Action": [ "s3:DeleteBucket", "s3:DeleteBucketPolicy", "s3:PutBucketPolicy" ], > > "Resource": [ > > "arn:aws:s3:::*" > > ] > > }] > > } > > > > Bucket cannot be deleted any more even by the bucket owner, and also the > > bucket policy can't be modified/deleted anymore. > > > > This closes the loopholes I could come up with so far; there might still > > be some left I am currently not aware of :-) > > > > > > On Wed, Oct 04, 2023 at 06:20:09PM +0200, Matthias Ferdinand wrote: > > > On Tue, Oct 03, 2023 at 06:10:17PM +0200, Matthias Ferdinand wrote: > > > > On Sun, Oct 01, 2023 at 12:00:58PM +0200, Peter Goron wrote: > > > > > Hi Matthias, > > > > > > > > > > One possible way to achieve your need is to set a quota on number of > > > > > buckets at user level (see > > > > > https://docs.ceph.com/en/reef/radosgw/admin/#quota-management). Quotas are > > > > > under admin control. > > > > > > > > thanks a lot, rather an elegant solution. > > > > > > sadly, bucket quotas are not really as effective and elegant as I first > > > thought, since "--max-buckets=0" means "unlimited", not "no buckets". > > > > > > Setting and enabling per-user bucket-scoped quota: > > > > > > # radosgw-admin quota set --uid=rgw_user_03 --quota-scope=bucket --max-objects=1 --max-size=1 --max-buckets=1 > > > > > > # radosgw-admin quota enable --quota-scope=bucket --uid=rgw_user_03 > > > > > > # radosgw-admin user info --uid=rgw_user_03 | jq '.max_buckets,.bucket_quota' > > > 1 > > > { > > > "enabled": true, > > > "check_on_raw": false, > > > "max_size": 1024, > > > "max_size_kb": 1, > > > "max_objects": 1 > > > } > > > > > > > > > "--max-buckets=0": number of buckets seems to be effectively unlimited > > > > > > "--max-buckets=1": the user can create exactly 1 bucket, further bucket > > > creation attempts get a "TooManyBuckets" HTTP 400 > > > response. > > > > > > Tried a negative number ("--max-buckets=-1"), but that had no effect at > > > all (not even an error message). > > > > > > I might pre-create a bucket for each user, e.g. a bucket named > > > "dead-end-bucket-for-rgw_user_03", so they are already at their maximum > > > bucket number when they first get their account credentials. > > > But can I also keep the user from simply deleting this pre-created > > > bucket and creating a new one with a name we intended for some other > > > use? > > > > > > Buckets of reserved names can't be pre-created (and pre-owned by some > > > special users) here, as the list of reserved names is not fully known, > > > only a few name prefixes are known so far (i.e. something like > > > "<application>-.*"), but even with these prefixes we do not have an > > > exhaustive list. > > > > > > > > > Regards > > > Matthias > > > > > > > > Rgds, > > > > > Peter > > > > > > > > > > > > > > > Le dim. 1 oct. 2023, 10:51, Matthias Ferdinand <mf+ml.ceph@xxxxxxxxx> a > > > > > écrit : > > > > > > > > > > > Hi, > > > > > > > > > > > > I am still evaluating ceph rgw for specific use cases. > > > > > > > > > > > > My question is about keeping the realm of bucket names under control of > > > > > > rgw admins. > > > > > > > > > > > > Normal S3 users have the ability to create new buckets as they see fit. > > > > > > This opens opportunities for creating excessive amounts of buckets, or > > > > > > for blocking nice bucket names for other uses, or even using > > > > > > bucketname-typosquatting as an attack vector. > > > > > > > > > > > > In AWS, I can create some IAM users and provide per-bucket access to > > > > > > them via bucket or IAM user policies. These IAM users can't create new > > > > > > buckets on their own. Giving out only those IAM credentials to users and > > > > > > applications, I can ensure no bucket namespace pollution occurs. > > > > > > > > > > > > Ceph rgw does not have IAM users (yet?). What could I use here to not > > > > > > allow certain S3 users to create buckets on their own? > > > > > > > > > > > > > > > > > > Regards > > > > > > Matthias > > > > > > _______________________________________________ > > > > > > ceph-users mailing list -- ceph-users@xxxxxxx > > > > > > To unsubscribe send an email to ceph-users-leave@xxxxxxx > > > > > > > > > > _______________________________________________ > > > > ceph-users mailing list -- ceph-users@xxxxxxx > > > > To unsubscribe send an email to ceph-users-leave@xxxxxxx > > > _______________________________________________ > > > ceph-users mailing list -- ceph-users@xxxxxxx > > > To unsubscribe send an email to ceph-users-leave@xxxxxxx > > _______________________________________________ > > ceph-users mailing list -- ceph-users@xxxxxxx > > To unsubscribe send an email to ceph-users-leave@xxxxxxx > > > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx > To unsubscribe send an email to ceph-users-leave@xxxxxxx _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |