AWS S3 IAM策略,用于对单个存储桶执行读写权限

Asa*_*uhi 2 ruby-on-rails heroku amazon-s3 railstutorial.org

在Michael Hartl'Rails教程的第11.4.4节" 生产中图像上传 "中,建议使用Amazon Web Services S3作为云存储服务.在页面底部的一个注释中,作者自己将本书的这一部分定义为"具有挑战性",并且还表明它"可以跳过而不会失去连续性".

实际上,本节最具挑战性的部分之一是找到一个合适的IAM策略,该策略可以附加到AWS的IAM用户,以便授予IAM用户对S3存储桶的读写权限.

我发现在Stackoverflow上这是一个常见问题:例如,请参阅" 尝试设置Amazon的S3存储桶:403禁止错误和设置权限 ".

实际上,Amazon Web Services针对需要对单个S3存储桶具有读写权限的应用程序的解决方案不起作用,并且尝试上载图像的用户从Heroku的AWS服务器接收403禁止状态.

预定义的"AmazonS3FullAccess"策略确实有效,但不应将其视为最终解决方案,因为不需要向IAM用户授予过多权限,因此也不需要向应用程序授予权限,而且我认为也可能是安全漏洞.

那么正确的IAM政策是什么?

Asa*_*uhi 6

如果'AmazonS3FullAccess'策略有效,那么肯定会有一些对应用程序工作至关重要的操作.

除了ListBucket,PutObject,GetObjectDeleteObject操作它们的存在似乎是合乎逻辑的,我发现,PutObjectAcl也是必要的.

从AWS的访问控制列表(ACL)概述:

"Amazon S3访问控制列表(ACL)使您能够管理对存储桶和对象的访问.每个存储桶和对象都有一个ACL作为子资源附加到它.它定义了哪些AWS账户或组被授予访问权限和访问类型.收到针对资源的请求后,Amazon S3会检查相应的ACL以验证请求者是否具有必要的访问权限.当您创建存储桶或对象时,Amazon S3会创建一个默认ACL,授予资源所有者对资源的完全控制权"

此外,从'PutObjectAcl'文档:

"此PUT操作的实现使用acl子资源为存在于存储桶中的对象设置访问控制列表(ACL)权限...对象的ACL设置为对象版本级别.默认情况下,PUT设置对象当前版本的ACL."

我在亚马逊论坛的支持请求中找不到解释为什么PutObjectAcl是必要的,但根据我的理解,可能是在第一次将对象上传到存储桶中时应该明确请求创建对象的ACL的操作由进行上传的应用程序(或IAM用户).您可以在上面的亚马逊论坛讨论及以下内容中找到我的政策副本:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::<bucket-name>"
    },
    {
      "Action": [
        "s3:DeleteObject",
        "s3:GetObject",
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::<bucket-name>/*"
    }
  ]
}
Run Code Online (Sandbox Code Playgroud)

还要考虑Heroku关于您的桶名称选择的建议:避免例如标点符号.