關注公衆號：AWS愛好者（iloveaws）
文 | 沉默惡魔（禁止轉載，轉載請先經過作者同意）
網站：www.iloveaws.cn
【 Domain 2-新解決方案設計】——-AWS STS – 以正確的方式設計IAM用戶密鑰
Hello大家好，歡迎來到《AWS解決方案架構師認證 Professional(SAP)中文視頻培訓課程》，我們前幾個視頻課程都在討論AWS STS服務，今天將繼續AWS STS服務的內容—使用STS服務，爲用戶分配臨時憑證訪問AWS資源。
我們開始今天的課程內容。
關注微信公衆號：AWS愛好者(iloveaws)
1、一個用戶案例：哪個方案最佳？
我們先看一個用戶案例，張三是一個開發人員，他要在他本地的電腦環境測試他的代碼。代碼需要訪問AWS S3，所以需要AWS的access & secret key 。那麼以下哪個方案是實現需求的最佳的解決方案？
這是一個普遍的案例，相信在大多數組織中都發生過，開發人員想要在本地的電腦上測試他的代碼，這樣的話就不能附加角色到EC2，然後在要求研發人員登陸EC2上去做測試。在這種情況下，有三種方案能夠滿足開發人員的測試需求：
第一個方案，提供給研發人員access & secret key，然後告訴他不要與其他人員共享憑證。相信很多組織都是這麼做的，可以滿足需求，但不安全，而且多年的工作經歷和教訓告訴我們，他是一定會和其他人分享憑證的。
第二個方案，提供給研發人員access & secret key，然後確保憑證每90天進行一次輪換，這種方式看似比第一種方式安全些，因爲增加了憑證的輪換。但是同樣，如果這個憑證被泄露，90天的輪換間隔是一個很長的時間間隔，在泄露後輪換時間前，同樣會造成安全隱患；而縮短輪換時間同樣不是一個很好的解決方案，尤其是您的組織有幾十、幾百個用戶需要憑證時，會給您的工作帶來很高的複雜度。所以整體這個方案也不太理想。
第三個方案是允許研發人員使用AWS STS服務生成臨時憑證，使用臨時憑證訪問資源。這個是最佳的解決方案。如果您在您的組織是解決方案架構師或者負責安全工程師，當開發人員或者其他人員請求憑證訪問AWS資源時，請您採用這個方案。
在上節課將EC2元數據的臨時憑證拷貝到了我本地的mac電腦，在本地訪問AWS資源，那不是一個很理想的方式，接下來看下滿足這個用戶案例最佳的實現方式，也就第三個方案的具體配置步驟。
2、AWS STS服務生成臨時憑證，使用臨時憑證訪問S3的實現步驟：
第三個方案是允許開發人員使用AWS STS服務生成臨時憑證，使用臨時憑證訪問S3。
所以我們要配置：通過將允許訪問S3的權限策略附加到角色，開發人員通過sts:Assumerole的方式獲得該角色的臨時訪問憑證，然後使用此臨時訪問憑證訪問AWS S3。
PPT的圖是最終的執行流程，非常清晰，開發人員在本地執行AssumeRole，然後IAM角色返回臨時憑證，然後用戶使用這個臨時憑證訪問S3，這種方式是AWS推薦的最佳實踐，而不是通過將持久性憑證分配給用戶直接使用。
所以接下來我們需要做三件事：
第一步，在IAM中建立一個跨賬戶角色
第二步，附加一個S3ReadOnly策略到IAM角色，讓這個角色有隻讀訪問S3的權限
第三步，允許IAM用戶也就是開發人員使用的用戶執行STS Assume Role 權限，獲得臨時憑證
最終開發人員使用臨時憑證訪問S3。
爲了加深大家的理解，還是老慣例直接實操演示：
3、實操演示-配置：
登陸AWS管理控制檯，進入IAM-用戶，我們目前已經創建了開發用戶zhangsan，沒有附加任何權限。
然後，切換到我本地mac的終端，我們後面假設這個就是開發人員zhangsan要調試代碼的終端，需要訪問S3存儲桶。
先看一下aws的credentials文件內容，我已經將zhangsan的訪問密鑰配置在了credentials文件的default中，可以覈對下，ID後4位UDVX，切換到控制檯，安全證書，密鑰id後四位是UDVX是一致的，已經在本地終端credentials文件配置了IAM用戶zhangsan的安全憑證。
我們現在在本地mac終端執行aws s3 ls ，返回的信息是訪問被拒絕，無法訪問，因爲現在zhangsan這個用戶沒有附加任何權限。
我們現在進行第一步和第二步，在IAM中建立一個跨賬戶角色，併爲該角色附加一個S3ReadOnly策略
進入IAM-角色-創建角色，有四個受信任實體的類型選項，我們在之前的視頻課程使用過受信任實體爲AWS產品-EC2，而這個案例研發人員要在本地調試，顯然這個選項無法滿足我們這個案例的需求。我們這次要選擇受信任實體的類型爲“其他AWS賬戶”，然後輸入這個賬戶的賬戶ID，大家還記得怎麼查吧？
在支持-支持中心，然後我們將賬戶ID複製進去， 然後下一步，附加權限策略我們選擇s3readonly，下一步， 角色名稱我們叫做stroll,然後創建角色。
現在角色已經創建完成了， 點擊新創建的角色stroll，可以看到目前該角色只有一個s3readonly的訪問策略，
在看一下信任關係，委託人principal的內容爲，所有在這個賬戶ID下的用戶，允許執行sts:AssumeRole動作。
我們對比下在之前的課程中的附加到EC2的角色的principal內容，指定的是EC2 service ，我們今天這裏指定的是賬戶arn，這裏的區別大家要留意。
好的，我們繼續
後面進行第三步，允許用戶zhangsan STS Assume Role 權限。
也就是要配置IAM用戶zhangsan允許執行STS Assume Role 權限，然後zhangsan就可以承擔我們之前創建的stroll角色，使用此角色臨時訪問憑證只讀訪問AWS S3
下面我們開始配置第三步。
進入到IAM-用戶-zhangsan，爲了能夠讓zhangsan執行STS Assume Role 權限，我們添加一個內聯策略，服務選擇STS，操作選擇assumerole,然後資源這裏，我們要選擇特定，需要指定允許zhangsan承擔的角色的arn，添加我們之前創建的角色的ARN，下一步，然後策略名稱我們就輸入AssumeRole，然後完成創建策略。
其實這裏有兩個策略限制對應的，第一個策略是允許zhangsan這個用戶承擔我們創建的stroll角色的權限，就是上一步配置的。
第二個是在我們前面演示的stroll角色的信任關係中，指定了能夠承擔stroll角色的可信任的實體內容爲所有在這個指定的賬號id的用戶,包括zhangssan都允許擔任該角色，大家還記得吧？
所以大家要記得這兩個對應關係。
PPT中的三個步驟我們配置完了，接下來就是要在我本地使用zhangsan用戶獲取我們創建角色的臨時憑證，然後使用臨時憑證訪問S3。
4、實操演示-驗證：
我們開始，切換到我本地的mac電腦終端，使用aws cli ，運行aws sts assume-role命令，爲zhangsan用戶生成我們創建角色stroll的臨時安全憑證。
爲了節省時間我已經將命令準備好了，cli命令以及對應的參數說明都可以到AWS的cli命令參考頁面查詢：
aws sts assume-role --role-arn arn:aws:iam::256454142732:role/stroll --role-session-name stroll
我們看下這個命令，aws sts assume-role，參數–role-arn後，需要指定要承擔角色arn，所以我們指定了我們創建的stroll角色的arn；–role-session-name指定唯一會話名稱，我們就指定stroll。
我們現在複製一下命令到我mac終端執行一下，看一下返回結果，命令成功將臨時憑證返回，包括accesskey secretkey以及session token等等。
我們現在執行下aws s3 ls，返回access denied ，還是禁止訪問。因爲我們這個zhangsan的用戶，目前擁有的唯一權限策略就是sts:assume role，他本身沒有s3相關權限。zhangsan需要通過以上這個aws sts assume-role命令返回stroll角色的臨時憑證，然後使用這個臨時憑證纔可以訪問S3。stroll是有s3readonly策略的，大家還記得吧。
所以我們現在編輯下aws credentials文件，將命令返回的臨時憑證信息放進去，我們新建一個zhangsansts字段，然後將憑證複製進去。保存退出
然後 執行aws s3 ls --profile zhangsansts
可以看到我們現在可以訪問S3存儲桶，我們用戶案例的演示就完成了。
以上這種授權訪問AWS資源的方式是AWS推薦的最佳實踐。
在補充一點知識，切換到AWS的assume-role命令參考頁面，看一下[—duration-seconds ]參數，可以通過此參數指定臨時憑證的過期間隔，默認爲1小時，超過間隔後憑證將會輪換。
以上就是我們今天的課程內容，我們今天演示了IAM用戶通過sts:assume role的方式，獲得角色的臨時訪問憑證，通過將訪問資源的權限附加到角色，然後用戶使用臨時訪問憑證訪問AWS資源。這種方式是AWS推薦的最佳實踐，將憑證安全維持到了一個很高的級別，而不是通過將持久性憑證分配給用戶使用這種粗放的方式。
好的，希望通過今天的課程，能夠讓大家更熟悉AWS STS服務。
希望此係列教程能爲您通過 AWS解決方案架構師認證 Professional 認證考試帶來幫助，如您有任何疑問
關注公衆號：AWS愛好者（iloveaws）
文 | 沉默惡魔（禁止轉載，轉載請先經過作者同意）
網站：www.iloveaws.cn