Hello Matthias, In our setup we have a set of users that are only use to read from certain buckets (they have s3:GetObject set in the bucket policy). When we create those read users using the Admin Ops API we add the max-buckets=-1 parameter which disables bucket creation. https://docs.ceph.com/en/quincy/radosgw/adminops/#create-user Isn’t this what are you looking for? Regards, Ondrej > On 6. 10. 2023, at 8:44, Matthias Ferdinand <mf+ml.ceph@xxxxxxxxx> wrote: > > 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 <mailto:ceph-users@xxxxxxx> > To unsubscribe send an email to ceph-users-leave@xxxxxxx <mailto:ceph-users-leave@xxxxxxx> _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |