If you want to do it using CLI in one command then try this “radosgw-admin user create --uid=test --display-name=“Test User" --max-buckets=-1” Ondrej > On 6. 10. 2023, at 9:07, Matthias Ferdinand <mf+ml.ceph@xxxxxxxxx> wrote: > > On Fri, Oct 06, 2023 at 08:55:42AM +0200, Ondřej Kukla wrote: >> 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? > > yes, it is, thank you. Seems to be essentially the same as providing > "--max-buckets=-1" on the CLI with "radosgw quota set". But interesting > to see this done in a single step when creating the user. > > Matthias > >> >> 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> <mailto:ceph-users@xxxxxxx> >>> To unsubscribe send an email to ceph-users-leave@xxxxxxx <mailto:ceph-users-leave@xxxxxxx> <mailto: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
 |