在第11.4.4章'Image upload in production ' of Michael Hartl' Rails教程中,建议使用Amazon Web Services S3作为 Cloud 存储服务 . 在页面底部的一个注释中,作者自己将本书的这一部分定义为"challenging",并建议将其作为"can be skipped without loss of continuity" .
实际上,本节最具挑战性的部分之一是找到一个合适的IAM策略,该策略可以附加到AWS的IAM用户,以便授予IAM用户对S3存储桶的读写权限 .
我发现在Stackoverflow上这是一个常见问题:例如参见'Trying to set up Amazon's S3 bucket: 403 Forbidden error & setting permissions' .
实际上,对于需要对单个S3存储桶具有读写权限的应用程序,Amazon Web Services's solution不起作用,尝试上载图像的用户从Heroku的AWS服务器接收403禁止状态 .
预定义的“AmazonS3FullAccess”策略确实有效,但不应将其视为最终解决方案,因为不需要向IAM用户授予过多权限,因此也不需要向应用程序授予权限,而且我认为也可能是安全漏洞 .
那么正确的IAM政策是什么?
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用户) . 您可以在上面的亚马逊论坛讨论及以下内容中找到我的政策副本:还要考虑Heroku's suggestions关于您的桶名称的选择:避免例如标点符号 .