Hi

First, all requests with presigned URLs should be restricted.

This is how the request is blocked with the nginx sidecar (it's just a 
simple parameter in the URL that is forbidden):

if ($arg_Signature) { return 403 'Signature parameter forbidden';

}

Our bucket policies are created automatically with a custom 
microservice. You find an example in attachment from a random "managed" 
bucket. These buckets are affected by the issue.

There is a policy that stops users from changing the policy.

I might have done a mistake when redacting replacing a user with the 
same values.

Thanks you and have a great day

Marc

On 12/9/23 00:37, Robin H. Johnson wrote:
> On Fri, Dec 08, 2023 at 10:41:59AM +0100,marc@singer.services  wrote:
>> Hi Ceph users
>>
>> We are using Ceph Pacific (16) in this specific deployment.
>>
>> In our use case we do not want our users to be able to generate signature v4 URLs because they bypass the policies that we set on buckets (e.g IP restrictions).
>> Currently we have a sidecar reverse proxy running that filters requests with signature URL specific request parameters.
>> This is obviously not very efficient and we are looking to replace this somehow in the future.
>>
>> 1. Is there an option in RGW to disable this signed URLs (e.g returning status 403)?
>> 2. If not is this planned or would it make sense to add it as a configuration option?
>> 3. Or is the behaviour of not respecting bucket policies in RGW with signature v4 URLs a bug and they should be actually applied?
> Trying to clarify your ask:
> - you want ALL requests, including presigned URLs, to be subject to the
>    IP restrictions encoded in your bucket policy?
>    e.g. auth (signature AND IP-list)
>
> That should be possible with bucket policy.
>
> Can you post the current bucket policy that you have? (redact with
> distinct values the IPs, userids, bucket name, any paths, but otherwise
> keep it complete).
>
> You cannot fundamentally stop anybody from generating presigned URLs,
> because that's purely a client-side operation. Generating presigned URLs
> requires an access key and secret key, at which point they can do
> presigned or regular authenticated requests.
>
> P.S. What stops your users from changing the bucket policy?
>

anything we can do to narrow down the policy issue here? any of the
Principal, Action, Resource, or Condition matches could be failing
here. you might try replacing each with a wildcard, one at a time,
until you see the policy take effect

On Wed, Dec 13, 2023 at 5:04 AM Marc Singer <marc@singer.services> wrote:
>
> Hi
>
> As my attachment is very messy, I cleaned it up and provide a much
> simpler version for your tests bellow.
> These policies seem to get ignored when the URL is presigned.
>
> {
>     "Version":"2012-10-17",
>     "Id":"userbucket%%%policy",
>     "Statement":[
>        {
>           "Sid":"username%%%read",
>           "Effect":"Allow",
>           "Principal":{
>              "AWS":"arn:aws:iam:::user/username"
>           },
>           "Action":[
>              "s3:ListBucket",
>              "s3:ListBucketVersions",
>              "s3:GetObject",
>              "s3:GetObjectVersion"
>           ],
>           "Resource":[
>              "arn:aws:s3:::userbucket",
>              "arn:aws:s3:::userbucket/*"
>           ],
>           "Condition":{
>              "IpAddress":{
>                 "aws:SourceIp":[
>                    "redacted"
>                 ]
>              }
>           }
>        },
>        {
>           "Sid":"username%%%write",
>           "Effect":"Allow",
>           "Principal":{
>              "AWS":"arn:aws:iam:::user/username"
>           },
>           "Action":[
>              "s3:PutObject",
>              "s3:DeleteObject",
>              "s3:DeleteObjectVersion",
>              "s3:ListBucketMultipartUploads",
>              "s3:ListMultipartUploadParts",
>              "s3:AbortMultipartUpload"
>           ],
>           "Resource":[
>              "arn:aws:s3:::userbucket",
>              "arn:aws:s3:::userbucket/*"
>           ],
>           "Condition":{
>              "IpAddress":{
>                 "aws:SourceIp":[
>                    "redacted"
>                 ]
>              }
>           }
>        },
>        {
>           "Sid":"username%%%policy_control",
>           "Effect":"Deny",
>           "Principal":{
>              "AWS":"arn:aws:iam:::user/username"
>           },
>           "Action":[
>              "s3:PutObjectAcl",
>              "s3:GetObjectAcl",
>              "s3:PutBucketAcl",
>              "s3:GetBucketPolicy",
>              "s3:DeleteBucketPolicy",
>              "s3:PutBucketPolicy"
>           ],
>           "Resource":[
>              "arn:aws:s3:::userbucket",
>              "arn:aws:s3:::userbucket/*"
>           ]
>        }
>     ]
> }
>
> Thanks and yours sincerely
>
> Marc Singer
>
> On 2023-12-12 10:24, Marc Singer wrote:
> > Hi
> >
> > First, all requests with presigned URLs should be restricted.
> >
> > This is how the request is blocked with the nginx sidecar (it's just a
> > simple parameter in the URL that is forbidden):
> >
> > if ($arg_Signature) { return 403 'Signature parameter forbidden';
> >
> > }
> >
> > Our bucket policies are created automatically with a custom
> > microservice. You find an example in attachment from a random "managed"
> > bucket. These buckets are affected by the issue.
> >
> > There is a policy that stops users from changing the policy.
> >
> > I might have done a mistake when redacting replacing a user with the
> > same values.
> >
> > Thanks you and have a great day
> >
> > Marc
> >
> > On 12/9/23 00:37, Robin H. Johnson wrote:
> >> On Fri, Dec 08, 2023 at 10:41:59AM +0100,marc@singer.services  wrote:
> >>> Hi Ceph users
> >>>
> >>> We are using Ceph Pacific (16) in this specific deployment.
> >>>
> >>> In our use case we do not want our users to be able to generate
> >>> signature v4 URLs because they bypass the policies that we set on
> >>> buckets (e.g IP restrictions).
> >>> Currently we have a sidecar reverse proxy running that filters
> >>> requests with signature URL specific request parameters.
> >>> This is obviously not very efficient and we are looking to replace
> >>> this somehow in the future.
> >>>
> >>> 1. Is there an option in RGW to disable this signed URLs (e.g
> >>> returning status 403)?
> >>> 2. If not is this planned or would it make sense to add it as a
> >>> configuration option?
> >>> 3. Or is the behaviour of not respecting bucket policies in RGW with
> >>> signature v4 URLs a bug and they should be actually applied?
> >> Trying to clarify your ask:
> >> - you want ALL requests, including presigned URLs, to be subject to
> >> the
> >>    IP restrictions encoded in your bucket policy?
> >>    e.g. auth (signature AND IP-list)
> >>
> >> That should be possible with bucket policy.
> >>
> >> Can you post the current bucket policy that you have? (redact with
> >> distinct values the IPs, userids, bucket name, any paths, but
> >> otherwise
> >> keep it complete).
> >>
> >> You cannot fundamentally stop anybody from generating presigned URLs,
> >> because that's purely a client-side operation. Generating presigned
> >> URLs
> >> requires an access key and secret key, at which point they can do
> >> presigned or regular authenticated requests.
> >>
> >> P.S. What stops your users from changing the bucket policy?
> >>
> > _______________________________________________
> > ceph-users mailing list -- ceph-users@ceph.io
> > To unsubscribe send an email to ceph-users-leave@ceph.io
> _______________________________________________
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-leave@ceph.io
>