本文旨在給剛準備上手/稀里糊涂上手AWS的小伙伴們非常簡單地普及一下AWS 的IAM文章，希望大家能在項目中逐漸深入地理解這些概念，AWS文章應該會做成一個系列。
IAM是什么？
AWS Identity and Access Management (IAM), 這是AWS的一個服務，幫助用戶安全地對AWS資源進行控制,這么說可能有點難懂，讓我們來看下AWS下的四個概念吧
用戶（User）：代表訪問AWS的終端用戶
可使用密碼來訪問AWS管理平臺
可使用Access Key ID和Secret Access Key并通過API, CLI或SDK的形式來訪問AWS服務
默認用戶沒有任何權限，我們需要用策略賦予每個用戶所需要的最小權限
組（Group）：擁有相同權限的用戶組合
擁有相同權限的用戶可以歸入一個組，方便權限的統(tǒng)一管理和控制
一個組可以擁有多個用戶，一個用戶可以屬于多個組
-
角色（Role）：角色可以分配給AWS服務，讓AWS服務有訪問其他AWS資源的權限
角色不包含任何用戶名/密碼
角色比用戶更加安全可靠，因為沒有泄露用戶名/密碼或者Access Key的可能性
舉個例子，我們可以賦予EC2實例一個角色，讓其有訪問S3的讀寫權限
策略（Policy）：定義具體訪問權限的文檔
策略具體定義了能訪問哪些AWS資源，并且能執(zhí)行哪些操作（比如List, Read, Write等）
策略的文檔可以JSON的格式展現(xiàn)
根用戶（Root User）
根用戶：在我們創(chuàng)建賬戶第一次登陸的時候，其實登陸的是根用戶，而AWS并不推薦使用根用戶來執(zhí)行日常任務,而應當使用被賦予了AdministratorAccess的用戶來管理日常任務（包括之后的為 AWS 賬戶設置其他組、用戶），使得這些用戶成為管理員。
通過為訪問賬戶的人員創(chuàng)建單獨的 IAM 用戶，可以向每個 IAM 用戶提供一組獨特的安全憑證。我們還可向每個 IAM 用戶授予不同的權限。如有必要，我們可以隨時更改或撤銷 IAM 用戶的權限。(如果公布了根用戶憑證，則很難將其撤銷，且不可能限制它們的權限。)
用戶(User)
在我們還提到了Access Key ID和Secret Access Key,這兩個其實是當我們操作cli或者編寫代碼的時候使用的,在我們創(chuàng)建成功用戶的時候便會給我們包含User name 、Password 、Access key ID、 Secret access key的 .csv文件
創(chuàng)建完成后，可以看到用戶可以被加到不同的組里了，這是在創(chuàng)建用戶的時候便可以設置的(這里我們沒有截圖出來這個步驟，大家可以自行去試一下)
在針對組的操作之前，我們還可以對用戶附加單獨的策略，如下圖所示，直接附加的策略是我們單獨給這個hao.gu2的用戶加的，而從組內附加的策略，我們可以去組內管理。
組(Group)
在組中，我們可以設置這個組內所有成員的AWS資源權限，比如下圖，我們可以大概從名字看出來，prod這個組擁有RDS、EC2全部的訪問權限，只有DynamoDB的read權限。
通過這種方式，我們就不用再每次創(chuàng)建一個新用戶的時候，耗時耗力地去給他添加策略了，只需要把他加到現(xiàn)有的組中，就可以完成這個用戶基本的權限控制，當這個用戶還需要額外的權限時，我們也可以單獨地附加給他。
策略(Policy)
那么這個策略是什么呢？AWS已經(jīng)給我們準備了各種各樣的通用策略，下圖是AWS已有的s3策略，一般情況下這些策略都是對所有的s3起效果，那么如果我們只想讓用戶訪問一個特定的s3資源呢該怎么做呢？
AWS提供給我們可視化的編輯器來編輯我們的策略，如下圖，我們可以選擇相對應的服務,，然后選擇我們賦予所需的權限操作，還可以指定這些操作哪個特定的S3，這些選項最后都會轉成Json格式保存起來。用戶只會獲得所有分配
關于Policy的邏輯可以設計的非常多樣化，但是仍然可以總結成一句話，只有具備顯式的 Allow，并且沒有顯式的 Deny，才有權限。
舉個例子：
如果同樣的資源既有Deny，又有Allow，那么最終會是Deny.
如果有一個資源沒有被Allow，那么就會被Deny
角色(Role)
終于輪到介紹角色了：
這是一個很容易與”用戶”混淆的的概念，IAM 角色非常類似于用戶，它具有確定其在 AWS 中可執(zhí)行和不可執(zhí)行的操作的權限策略。但是，角色沒有任何關聯(lián)的憑證（密碼或訪問密鑰）。角色旨在讓需要它的任何人代入，而不是唯一地與某個人員關聯(lián)。IAM 用戶可擔任角色來暫時獲得針對特定任務的不同權限。
看起來似乎“用戶”也能很好的完成這些任務，那么為什么還需要”角色”這個概念呢？
我們來看一看”角色”這一概念的應用場景:
-
AWS服務角色（例如：EC2，Lambda，Redshift等）
我們的用戶的策略是針對用戶的賬號而言的，我們可以限制登錄這個賬號的人能去做什么，不能做什么，那么怎么控制某個AWS的服務他的功能呢？
這個時候”角色”就出場了，比如我們可以創(chuàng)建一個EC2的角色，并賦予他一些Policy，使其只能訪問S3(如果沒有賦予角色，默認是不能訪問其他的AWS資源的)，這樣我們就能做到控制AWS服務的功能，
在上面這個例子中明顯是不適合用戶的場景，EC2只是我們的服務，他不應當有用戶這個概念，但是我們需要做的事情又跟”用戶”很像，都是去控制他所能做的事，那么就有了角色這個概念。
image-20210124222805157image-
實施最小權限原則
這指的是僅限特定任務需要時，才能使用提升的權限。借助角色，我們可以幫助防止對敏感環(huán)境進行意外更改，
舉個栗子：
假如有這么一個EC2實例，上面跑著公司最核心的業(yè)務代碼，我們可以創(chuàng)建具有停止權限的角色，而不是直接向用戶授予終止實例的權限。
當我們想終止這個EC2時，我們需要切換角色，才能執(zhí)行終止操作。
-
跨賬戶訪問：從其他AWS賬戶向用戶授予權限，無論我們是否控制這些賬戶。
我們可以向 IAM 用戶授予權限，以便切換至我們自己活著我們擁有的其他 AWS 賬戶中定義的角色。
這個場景非常常見，比如某個組織通過多個AWS賬號將開發(fā)環(huán)境和生產環(huán)境隔離，開發(fā)賬戶中的用戶有時可能需要訪問生產賬戶中的資源。
當然我們可以在兩個賬戶中工作的用戶創(chuàng)建單獨的身份 (和密碼)，但是這種情況下我們還需要管理多個賬戶的憑證，帶來一些困擾。
這個時候就可以通過角色來方便地管理這一點啦。
舉個例子：
- 在Prod賬號(123123123123)中創(chuàng)建一個UpdateAPP的角色使其能對Prod賬號下的S3讀取和寫入，并且定義信任策略，將Dev賬號指定為Principal。
- 在Dev賬號(456456456456)中授予用戶切換為角色的權限。這樣我們就可以在Dev賬號中切換成Prod賬號的角色，來操作Prod賬號下的AWS資源了。
如下圖所示，先在Prod賬號(123123123123)中創(chuàng)建一個給Dev賬號(456456456456)用的角色，并且賦予該角色訪問S3的權限，最后到Dev賬號(456456456456)中賦予用戶切換角色的權限(此處省略)，然后切換角色，輸入Prod賬號(123123123123)和角色名即可切換了,通過這種方式，我們不用登出自己的賬號便可訪問其他賬號下的資源。image-20210124222850028image-20210124222906613image-20210124222931407好啦，以上就是IAM最主要的四個概念的簡單介紹，希望大家不要像我一樣過了SAA結果這些概念還是稀里糊涂，考試就只顧著刷題去了。略過了不少子概念是因為想把這篇文章變得簡單易理解，而不是像用戶手冊一樣，而用戶手冊AWS已經(jīng)有了。如下鏈接
https://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/access_policies_managed-vs-inline.html
TODO:
AWS Cli整合IAM
AWS Organization
-
-
