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@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
