AWS S3 Web Console覆盖存储桶策略 [英] AWS S3 Web Console overriding bucket policy

查看:88
本文介绍了AWS S3 Web Console覆盖存储桶策略的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当前,我已将一个策略应用于测试存储区,该策略旨在防止用户使用"public-read"和"public-read-write" ACL上传s3object.

Currently I have a policy applied to a test bucket that is designed to prevent users from uploading s3objects with "public-read" and "public-read-write" ACLs.

当我尝试通过命令行上传时,请求已按预期成功被访问被拒绝"阻止:

When I try to upload via command line the requests are successfully blocked with "Access Denied" as expected:

Write-S3Object -bucketname testbucket -File C:\Users\user\Desktop\DemoFolder\secret_data.txt -cannedACLName public-read  

与"public-read-write"的结果相同:

Same result with "public-read-write":

Write-S3Object -bucketname testbucket -File C:\Users\user\Desktop\DemoFolder\secret_data.txt -CannedACLName public-read-write 

但是,当我通过Web控制台GUI访问s3bucket时,我可以上传公共对象.以及通过设为公开"按钮来将现有的私有"对象公开.

But when I access the s3bucket via the Web Console GUI I am able to upload public objects. Along with manipulating an existing "private" object to public via the "make public" button.

以下是存储桶策略:

{
"Version": "2012-10-17",
"Statement": [
    {
        "Sid": "DenyPublic",
        "Effect": "Deny",
        "Principal": "*",
        "Action": [
            "s3:PutObject",
            "s3:PutObjectAcl"
        ],
        "Resource": "arn:aws:s3:::testbucket/*",
        "Condition": {
            "StringEquals": {
                "s3:x-amz-acl": [
                    "public-read",
                    "public-read-write"
                ]
            }
        }
    }
]

这也是用户进行s3访问的策略:

Also here is the policy for s3 access from the user:

{
"Version": "2012-10-17",
"Statement": [
    {
        "Effect": "Allow",
        "Action": "s3:*",
        "Resource": "*"
    }
]

}

我觉得解决方法或逻辑很简单.我只是无法将手指放在上面.

I feel like the fix or logic is really simple. I just cannot put my finger on it.

推荐答案

我认为这里发生的是AWS控制台未触发您的拒绝策略,因为它未使用罐头ACL.相反,它是在上传文件后明确授予AllUsers组READ_ACP权限(使用x-amz-grant-read标头).

I think what's going on here is that the AWS Console is not triggering your Deny policy, because it's not using canned ACLs. Instead, it's explicitly granting the READ_ACP permission to the AllUsers group (using the x-amz-grant-read header), after uploading the file.

我建立了类似的策略,并在PutObject上测试了罐头ACL方法(失败):

I set up a similar policy and tested the canned ACL approach on PutObject (it failed):

$ aws s3 cp myfile s3://B/K --acl public-read
Result: Access Denied

然后,我测试了非ACL副本,然后使用固定ACL方法对对象进行了ACL更新(上传成功,但ACL更新失败):

Then I tested a non-ACL copy, followed by an ACL update to the object using the canned ACL approach (the upload succeeded, but the ACL update failed):

$ aws s3 cp myfile s3://B/K
Result: OK

$ aws s3api put-object-acl --bucket B --key K --acl public-read
Result: Access Denied

然后,我与AllUsers组一起尝试了授予方法(成功):

Then I tried the grant approach with the AllUsers group (it succeeded):

$ aws s3 cp myfile s3://B/K
Result: OK

$ aws s3api put-object-acl --bucket B --key K --grant-read uri=http://acs.amazonaws.com/groups/global/AllUsers
Result: OK

最后两个测试试图做同一件事(上载对象并使它在世界范围内可读取),但是它们以不同的方式进行操作,其中一个被您的策略拒绝,而另一个则未被.

The last two tests attempt to do the same thing (upload an object and make it world-readable) but they do it in different ways and one is denied by your policy while the other is not.

这篇关于AWS S3 Web Console覆盖存储桶策略的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆