> 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.c...@mfedv.net> 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@ceph.io
> > > > To unsubscribe send an email to ceph-users-le...@ceph.io
> > > >
> > _______________________________________________
> > ceph-users mailing list -- ceph-users@ceph.io
> > To unsubscribe send an email to ceph-users-le...@ceph.io
> _______________________________________________
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
