ruby-on-rails - 针对单个存储桶的读写权限的 AWS S3 IAM 策略

Question

在第 11.4.4 章 ' Image upload in production ' of Michael Hartl' Rails Tutorial 建议使用 Amazon Web Services S3 作为云存储服务。在页面底部的注释中，作者自己将本书的这一部分定义为“具有挑战性”，并建议“可以跳过而不失去连续性”。

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

我发现这是 Stackoverflow 上的一个常见问题:例如参见“Trying to set up Amazon's S3 bucket: 403 Forbidden error & setting permissions” '。

实际上，Amazon Web Services's solution对于需要对单个 S3 存储桶进行读写权限的应用程序不起作用，并且尝试上传图像的用户从 Heroku 的 AWS 服务器收到 403 禁止状态。

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

那么正确的 IAM 策略是什么？

Answer 1

如果“AmazonS3FullAccess”策略有效，那么其中肯定应该有一些对于应用程序工作必不可少的操作。

除了ListBucket , PutObject , GetObject和 DeleteObject其存在似乎合乎逻辑的行为，我发现 PutObjectAcl也是必要的。

来自 AWS 的 Access Control List (ACL) Overview :

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

此外，来自 documentation on 'PutObjectAcl' :

“这个PUT操作的实现使用acl子资源来为已经存在于桶中的对象设置访问控制列表(ACL)权限......对象的ACL是在对象版本级别设置的。默认情况下，PUT设置对象当前版本的 ACL。”

我在 my request of support 中找不到解释来自亚马逊论坛关于为什么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>/*"
    }
  ]
}

还要考虑 Heroku's suggestions关于您的存储桶名称的选择:例如避免标点符号。