The Art of Readable Code && High Performance Comments

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)

5 Comments

3 Pings/Trackbacks

  1. 2014 年 06 月 26 日    

    […] SSL or HTTPS termination proxy 時,需要先透過 IAM 上傳 server certificate (註:CF 的 crt 只能透過 aws cli 由 root account 上傳,ELB […]

  2. 2014 年 05 月 29 日    

    […] 簡述 IAM […]

  3. […] 簡述 IAM […]

  4. kakashi kakashi
    2014 年 05 月 25 日    

    我覺得講的部分, 不會糟啊, 純粹是因為時間太趕XD~~

    另外有關IAM的部分, 最近讀到像是S3可以直接對bucket設定權限,
    卻也可以用IAM設定, 不知道你比較推薦哪一種方式,..

    很期待下一篇的STS啊!

    • clifflu clifflu
      2014 年 05 月 26 日    

      S3 是目前少數有雙 Policy 可用的服務;如果我沒記錯,常用服務中只剩下 RDS (EC2-Classic) 能寫自己的 Policy。關於 S3 Policy的設計概念,ACL 部份像是舊世代產物,SOAP + XML 你懂的(但目前 CORS 必須使用 ACL / XML 設定)。至於 Bucket / User Policy 的取捨,S3 Manual 裡稍有著墨。我手邊沒有多的 amazon 帳號可以測試,因此下面全是猜想 :p

      若要將 root_A 帳號的 bucket 授權給 root_B 讀取,可以在 bucket 設定 bucket policy 授權給 root_B;而 root_A 及 root_B 可用 user policy 授權其下 IAM User 存取該 bucket。root_B 下的 IAM User 存取該 bucket 的過程,與存取 root_B 的 bucket 無異。

      同樣的功能可透過 IAM role 達成,但選為「AWS acounts you own」與「3rd party」的程序不太一樣;前者與 bucket policy 相同,後者則要透過 STS Assume Role 的方式授權。

      退一步想,Bucket 與 User Policy 格式接近,甚至 IAM Policy 中的 arn / Principal / account 都允許填入其他值;很可能 User Policy 便已足夠 XD 徵求勇者出借 AWS root account 追求真相!

  1. 開心玩 ELB | clifflu 又架 blog 了 O.o/ on 2014 年 06 月 26 日 at 03:32:48
  2. IAM Role 與 STS | clifflu 又架 blog 了 O.o/ on 2014 年 05 月 29 日 at 15:15:03
  3. AWS DynamoDB & JS SDK in the Browser | clifflu 又架 blog 了 O.o/ on 2014 年 05 月 29 日 at 15:08:45

發表迴響

分類

%d 位部落客按了讚: