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，纔會放行