我创建了一个组,然后我向该组添加了新用户,然后我创建了以下IAM策略:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "arn:aws:s3:::*" }, { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::EXAMPLE-BUCKET-NAME" }, { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::EXAMPLE-BUCKET-NAME/*" } ] }
我从上面得到了上述政策:
http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html
基本上,我只想为一个特定的存储桶授予权限,但上述策略不起作用。用户仍然可以添加,删除,修改其他存储桶中的文件。
谢谢!
答案 0 :(得分:0)
此政策绝对可行 - 用户只能添加/删除/修改EXAMPLE-BUCKET-NAME存储桶。
仔细检查您的群组和用户,确保没有附加其他托管或内联政策。
答案 1 :(得分:0)
尝试将IAM角色用于S3存储桶,并为每个用户使用角色。那应该限制对存储桶的写访问。
检查链接中有关授予访问权限的部分。
希望有帮助!
答案 2 :(得分:0)
对于 Google 员工:
S3 API 和 IAM 操作命名完全爆炸:
ListBucket
是一个弃用的 SOAP API,现在更名为 ListObjects
ListBuckets
是一个 API,用于列出 您的 API 调用者帐户ListBucket
API 受s3:ListBucket
IAM 操作ListBuckets
API 受...suprise❗️ s3:ListAllMyBuckets
IAM 操作ListBuckets
返回一个名为...surprise 的对象❗️ <ListAllMyBucketsResult>
我找不到一个很好的方式来描述我现在的感受。
永远保留旧 API 或错误命名的 API 以获得最佳向后兼容性可能是一个好习惯,但 AWS 在创建新 API 时应将一致性放在首位。
简而言之:ListBuckets
= s3:ListAllMyBuckets
,忘记s3:ListBucket
!
话虽如此,截至 2021/01 年,没有办法:
ListAllMyBuckets
,顾名思义,只接受*
作为有效资源ListBuckets
是获取此信息的唯一方法