AWS IAM Logo

還債系列

緣起

昨天在 AWS User Group Taiwan #7 給了一個頗糟的 Talk,時間與內容控制不太恰當 T_T 因此決定將講題內容拆成幾部份,分別在 blog 中介紹,才不會辜負自己準備的時間;也希望作為與會者的補償,方便挑選適合自己的主題。

簡介 AWS API 與 IAM

AWS 架構遵從 SOA 原則,因而將各類服務透過 API 鬆散耦合,以避免各模組間相互干擾;除了高階如 RDBMS (RDS)、Queue (SQS) 以外,底層的網路 (VPC)、虛擬機 (EC2) 也都有各自的 Web API,便於透過程式玩弄操作。而為了控制各方用戶調用 API 的權限,IAM 便隨之而生,以作為 AWS 的權限樞紐。

更確切的說,客戶端在調用 API 時,必須以特定的 Access / Secret Key Pair 簽署 http request;而 IAM 則是管理 key pairs,並設定其權限的平台。

IAM 基礎

首先,每個 Amazon 帳號在 AWS 裡,被稱作「Root Account」,並具有完全之權限。然而任何系統安全指南都建議避免以 Root Account 執行日常,因此 IAM 最根本的用途,便是創建 IAM Group 與 IAM User。

如同 Root User,IAM User 可以持有自己的帳號密碼,用以登入主控台 (Management Console);也可以持有自己的 Access / Secret Key Pair,進行 API 呼叫。無論用戶以何種方式登入,只要授權為該 IAM User,他在該服務的主控台與調用 API 的權限都是一樣的。事實上,主控台之頁面正是以用戶身份發送 API 請求,來取得要呈現的資料。

IAM 的權限係以 Policy 指定,其為  JSON 格式,例如:

  • #3: 同一則 Policy 下,可以有多個 Statement,因此使用 array ([]) 關鍵字
  • #5: Effect: 該則 Statement 之作用為允許 (Allow) 或禁止 (Deny)
  • #6: Action: 適用的 API call
  • #7: Resource: 格式為 arn, 後述
  • #8: Condition: 當滿足其中條件時,該項規則才被觸發(並允許或禁止對特定資源調用指定的 API)
  • #8-9: “s3:prefix” 是一個 Policy Variable,代表企圖存取的 s3 object path (或稱作 key);${aws:username} 是另一個 Policy Variable,會被帶換成登入的 IAM User name。

因此上面的 Policy 授權 IAM 用戶對 “BUCKET-NAME” 這個 bucket,並且 path 為 “”, “home/” 或 “home/${aws:username}/” 時,調用 s3:ListBucket 這隻 API。

當有多組符合的 Policy 時,判斷依據如下:

  1. 解析 Resource, Action 等關鍵字,篩選出對應的 Statements
  2. 若有任何一組 Statement 拒絕 (Effect: Deny) 授權,則拒絕
  3. 若有任何一組 Statement 允許 (Effect: Allow) 授權,則授權
  4. 預設為拒絕

官方提供的 Policy Builder 老實說並不好用;我個人建議直接透過 IAM console 進行測試。但要注意 IAM 的 policy 並非即時更新(Eventually Consistent),短時間內發生各類怪奇結果也不用太意外 🙂 另外 json 格式不支援註解,因此可以透過調整 Condition 等篩選條件,以暫時啟用或停用某項規則。

Amazon Resource Name (ARN)

表示 AWS 內的資源,包含以冒號分隔的多個欄位:

  • 最前兩節固定為 aws 與 arn
  • 服務名稱,例如 iam, dynamodb
  • region, 例如 ap-northeast-1, 某些服務可省略
  • account, 帳號號碼(一堆數字,不帶分隔符號),可省略
  • resource identifier,依照各服務而有差異;可能是 *, aaaa, aaa/bbb, aaa:bbb 等格式

可參考官方文件

IAM User 與 Group

因此我們可以分析用戶或專案所需最低權限,寫成適當的 Policy 並賦予對應用戶;而該用戶可以透過帳號密碼登入 Management Console,並管理自己的 Access & Secret Key Pair 來使用 AWS 資源。

有些時候,會有多組 User 需要類似權限(例如開發團隊的員工要能管理某些 S3 bucket,啟動 EC2 主機),便可以將權限指定給 Group,則該群組的用戶自然擁有該權限。搭配 Policy Variable 會有更多彈性。

下一篇將會講述 IAM 的進階運用,包含 IAM Role 與 Security Token Service (STS)