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
