AWS权限冲突-IAM Policy, S3 Bucket Policy 和 Bucket ACL

背景

AWS S3的权限设置一直是一个重难点，并且是比较混淆的一个概念。比较混淆的地方在于，用户能够经过三个不一样的地方进行权限管理，这三个地方分别是 IAM Policy， Bucket Policy 以及 Bucket ACL。

首先简单的说明一下他们的应用场景，IAM Policy是global级别的，他是针对用户来设置的，好比一个用户对全部的S3Bucket拥有get和list权限，那他就能够浏览任何一个Bucket的内容； 相较而言，S3 Bucket Policy仅仅是针对单个Bucket 而言的，他能够控制不一样用户对他自己的访问权限；Bucket ACL是一个早期的服务，如今用的比较少了，可是若是咱们须要对Bucket其中的具体对象配置访问权限，咱们须要使用Bucket ACL。

下面经过一些简单的例子来看看这三个东西究竟是怎么用的，若是有了冲突的设置，顺序是怎么处理的。

例1 IAM Policy

首先在IAM里面建立一个 Group，我给这个Group attach一个AWS Managed的 Policy，这个自带的policy容许S3 的只读权限

测试一下，发现只能浏览，可是不能上传

接下来，本身自定义一个Policy，自定义这个Policy容许用户上传文件

把这两个Policy都attach到咱们的Group上，这个Group里面的User就能够浏览全部的Bucket，也能够上传文件了，当多个Policy 都关联到一个用户或者组的时候，他的权限是并集集合。

测试一下 ，上传测试成功

例2 Bucket Policy

接下来，我新建一个Bucket ，随便取名叫作 beanxyzbucket1234, 确保全球的惟一性，全部权限都是默认设置

咱们来建立一个Bucket Policy ，在这个Policy里面我定义指定用户能够上传文件。这个Policy能够经过 Policy Generator来建立

首先获取对应的Bucket的ARN和用户的ARN，保存在记事本上

执行建立向导，容许 user1 在 我这个测试的bucket上进行delete 操做

他会自动生成一个JSON 的配置文件

复制粘贴这个JSOn文件过去试试，竟然报错！！

事实上，这是一个已知的bug，咱们须要手动的修改Resource，后面添加/和星号 , 表示这个bucket里面全部的资源

接下来用user1 登陆，进入这个Bucket，删除文件，测试成功

结论：这里能够看出来，个人两个IAM Policy 分别授予了user1 对全部的Bucket都有读取和上传的权限；个人Bucket Policy 授予了这个用户在这个 bucket上 删除文件的权限，而后他的最终权限是三者的并集。

例3 建立第二个bucket，在这个bucket上面，我也建立一个bucket policy，禁止全部人访问这个bucket

一样的，经过Policy Generator 来建立policy的JSON文件

自动生成的JSON文件，这个就不须要手动修改了

User1访问这个Bucket看看，果真没有权限访问了

结论：Deny 的权限高于一切 Allow的权限。尽管个人IAM Policy容许用户访问和上传，可是Bucket Policy 禁止一切操做，所以最后的权限是Deny

例4 ACL

Bucket 级别的ACL通常不推荐使用，毕竟是一个过期的服务。咱们这里是针对单个文件的ACL访问权限的设置。

回到咱们的第一个Bucket，先上传一个测试文件

Block public Access这里须要关掉，否则ACL会提示Access Denied

点击 Object，选择test.txt的Permission 设定。注意我这里修改的是单个文件的ACL访问权限，而不是整个Bucket的ACL

把Everyone Object 权限改成 Read

这样咱们就能够从Object URL的链接打开这个文件了

打开看看

值得一提的是，咱们这里没有强制https的访问，所以咱们用http也是能够打开这个文件的

若是回到S3的控制界面，咱们能够看见这个Bucket的Access变成了 Objects can be public，意思是咱们没有共享整个Bucket，而仅仅是共享了其中的一些对象文件

例5 强制 HTTPS访问

例4里面 咱们经过配置对文件对象的ACL容许public访问单个文件，可是由于没有强制https的访问，用户经过http也是能够访问的。

咱们在这个Bucket上建立一个新的Bucket Policy，以下所示

执行以后，发现咱们的https连接仍然是工做的，可是http就不行了

例6 禁止

最后，若是我把以前我自定义的IAM Policy 修改一下，我 Deny 全部的 Read 和 Put 操做，这样个人User1用户应该没法访问任何Bucket了

测试看看，的确是这样

可是有趣的是，我仍然能够经过http/https访问个人测试文档

这是为何？这是由于咱们的test.txt 文件的 ACL设定是容许public 任何人访问，所以任何匿名访问都是容许的，这里不存在任何验证机制，所以咱们的IAM Policy的限制没有起做用

最后，咱们来看看若是咱们同时启用了3种受权方式，如何判断最终的用户权限。基本规则以下所示：

1.默认初始权限都是Deny。好比我建立了一个用户 可是没有给他配置任何Policy，那么他什么都无法访问
2.明肯定义的Deny比Allow的权限高，若是在任何一个服务里面配置了Deny，那么这个Deny的优先级最高
3.若是没有明肯定义Allow，那么默认请求会被Deny
4.只有在没有明肯定义Deny的状况下，又明肯定义了Allow，才会放行