如何用 G Guite 整合 AWS Single Sign-On


整理如何設定 AWS SSO 的流程,主要參考: How to Set Up Federated Single Sign-On to AWS Using Google Apps 這篇文章,用 SAML 2.0 (Security Assertion Markup Language) 協議做使用者的 認證管理 (Authentication),並且延伸管理上實際遇到的問題。


需求背景

  • 集中 Authenticaion,使用單一來源
    • Authoriziation 則是使用 AWS IAM Policy
  • 多個 AWS 帳號 (十多個) 在使用,拆分主要是跟帳務有關係
  • 使用人員,有多個身份,通常是因為必須參與多個專案
  • 要減少 IAM User 帳號的發放,避免人員異動時疏漏
    • 簡化權限發放流程
  • 需要滿足 AWS Console and Programmatic User 的需求
    • 部分需要 IAM Credential 的應用程式,還是使用既定流程

設定

前提與主要流程

設定之前,先要有以下的條件:

  • 有 G Guite Admin 的權限
    • 準備幾個可使用帳號 (非群組),像是 rick@abc.com, jack@abc.com
    • 這些帳號模擬不同角色,像是團隊、Tech leader、Read Only … etc.
  • 有 AWS IAM Admin 的權限

設定步驟

主要的設定步驟大約如下:

  1. 在 G Suite Admin Console 取得 IdP metadata 與 customer ID
  2. 在 AWS IAM 新增 Identity Providers
  3. 在 AWS 建立登入的角色 Role 與權限
  4. 在 G Suite 設定 user profile
  5. 在 G Suite 設定 SAML app

SMAL 相關名詞

  • IdP: Identity Provider, 身分提供者
  • SP: Service Provider, 即服務提供者

一、取得 IdP metadata

  • 使用 Admin 權限身份,登入 admin.google.com
  • 安全性 -> 設定單一登入 (SSO)
    • 下載 IdP Meta,這是個 XML 檔,保存好。

紀錄 idpid (截圖中紅色消掉部分) 後面會使用

二、在 AWS IAM 新增 Identity Providers

  • 使用有 Admin 權限的使用者登入 AWS Console
  • 到 IAM -> Identity providers -> Create Provider
    • Provider Type 選 SAML
    • Provider Name: 輸入一個可以識別的名稱
      • 建議以 DNS 名稱命名,多個 Provider 時容易識別
      • 這個名稱會當作 ARN 名稱,不能有空白、特殊字元
    • 選擇 Metadata Document,上傳上個步驟的下載的 IdP Meta

如下圖:

完成此動作後,記錄 Provider ARN,後面會使用。

三、在 AWS 建立登入的角色 Role 與權限

與以往不一樣的是 trusted entity 類型的選擇,本文的主角是:SAML 2.0 federation

另外要注意的是 Role Naming,名稱是以使用者面向命名,以便未來使用者方便知道現在在哪個 AWS Account。下圖中的範例,我的命名規則是這樣:

SSO-{AWS_ACCOUNT_NAME}-{ROLE_NAME}

  • SSO- 做命名的前置詞,識別是哪一種登入方式。其他像是跨帳號 (Cross Account) 則使用 CA- 開頭
  • AWS_ACCOUNT_NAME: 每個 AWS Account 我都會取一個唯一的是別名字,例如 Abc-Dev, Abc-QA, Abc-QA,下圖的範例是 GTCafe-Dev
  • ROLE_NAME: 最後則是實際的角色名稱

完成此動作後,記錄 Role ARN,後面會使用。

四、在 Google Admin API 設定 User profile

這個步驟有兩個動作執行,主要是用 Google Admin API 做以下兩個步驟。

步驟一:建立 schema,點 Schema:Insert 開啟 Google Admin API。在畫面右邊的 Try this API 填入以下參數:

  • customerId: 填入第一步取得的 idpid
  • Request Body 填入以下範例。
    • schemaName 是參考名稱,後面會使用。
    • displayName 是 field 的顯示名稱,沒填後面步驟五選單會選不到。
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      {
      "displayName": "SSO",
      "fields": [
      {
      "fieldName": "role",
      "fieldType": "STRING",
      "readAccessType": "ADMINS_AND_SELF",
      "multiValued": true,
      "displayName": "role"
      }
      ],
      "schemaName": "SSO-AWS"
      }

如果有 API KEY,也可以直接使用以下的 curl:

1
2
3
4
5
6
7
curl --request POST \
'https://www.googleapis.com/admin/directory/v1/customer/[customerId]/schemas?key=[YOUR_API_KEY]' \
--header 'Authorization: Bearer [YOUR_ACCESS_TOKEN]' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data '{"displayName":"SSO","fields":[{"fieldName":"role","fieldType":"STRING","readAccessType":"ADMINS_AND_SELF","multiValued":true,"displayName":"role"}],"schemaName":"SSO-AWS"}' \
--compressed

步驟二:建立使用者與 ARN 授權關聯,這個步驟會是未來維護權限最常修改的部分。點 Users:Path 開啟 Google Admin API。

  • userKey: 填入 G Guite 上的使用者帳號,像是 `rick@abc.com`
  • Request Body: 這裡會關聯到前步驟建立的 schema,同時關聯使用者對應到 AWS 哪一個 SSO Provider 與 IAM Role,基本的格式如下:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    {
    "customSchemas": {
    "SSO": {
    "role": [
    {
    "value": "<IAM_ROLE_ARN>,<PROVIDER_ARN>",
    "customType": "Admin"
    }
    ]
    }
    }
    }

實際上,一個人可能會需要登入多個 AWS 帳號,然後有多個身份(團隊、部門)等,底下的範例是有兩個 AWS 帳號,然後有三種角色:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
"customSchemas": {
"SSO": {
"role": [
{
"value": "arn:aws:iam::123456789012:role/SSO-GTCafe-Admin,arn:aws:iam::123456789012:saml-provider/GSuite_GTCafe",
"customType": "Admin"
},
{
"value": "arn:aws:iam::012123456789:role/SSO-GTCafe-Admin,arn:aws:iam::012123456789:saml-provider/GSuite_GTCafe",
"customType": "Admin"
},
{
"value": "arn:aws:iam::123456789012:role/SSO-GTCafe-ReadOnly,arn:aws:iam::123456789012:saml-provider/GSuite_GTCafe",
"customType": "ReadOnly"
}
]
}
}
}

實際的管理流程,主要 Authentication 就是控制一段,另外 Authorization 則是在 IAM Policy 控制。

五、在 G Suite 設定 SAML app

用 Admin 帳號到 G Guite Admin Console,到 應用程式 -> SMAL App,新增 APP 選擇 Amazon Web Services,大部分步驟都是先是預設值即可,如下:


步驟五的 Attribute Mapping 設定如下:

  • Basic Information: Primary Email
  • SSO: Role,這是在前面步驟四在 Google Admin API 所增加的 schema 名稱

完成後,開放讓所有人可以存取此 APP。

使用 SSO 登入 AWS Console

開啟 Chrome ,確認已經是登入的狀態,可以從右上角的使用者狀態,或者上面中間的選單 People 登入,確認登入後,開啟空白選單 (Ctrl + Tab),會看到右上角的 G Guite App 選項,如下圖:

登入後,如果是有多帳號、多角色,那麼會看到類似底下的選項:


問答

Q: 使用 G Suite 登入 AWS,那麼需要先有 AWS IAM User?

不需要,只要有 G Suite 上的帳號,以及 AWS IAM Role 即可

Q: 可以用 Browser 同時登入多個身份嗎?

不可以,如果要同時使用多個身份同時登入,只能用不同的瀏覽器,然後都登入 google 之後才能可以直接登入。

Q: IAM Programmitc User 可以使用此方法?

目前我沒找到方法,所以還是需要開 IAM 帳號。

Q: Federated SSO 與 Cross Account Role 的做法比較,哪個好?

Cross Account Role (Switch Role) 好處是可以在同一個 Browser 快速切換帳號,動作是直接點選右上角的歷史選項。缺點:

  • AWS Console 只會記住五個 Role,Federated SSO 沒此問題。
  • 如果 Role Name 有調整,那麼 Admin 要通知很多人去修改,Federated SSO 沒此問題,使用者只要看得懂就可以了。

Federated SSO 也有缺點:切換帳號的動作比較多。

Q: 透過 Federated SSO 登入,一小時就過期了,可以延長?

在 IAM Role 的 Summary,找到 Maximum CLI/API session duration 調整即可,最大 12 小時。或者透過 AWS CLI 的 aws iam update-role --max-session-duration 更新,參閱 iam update-role


結論

最後整理 Federated SSO 與 Cross Account Role 的比較表:

項目 Switch Role Federated SSO
登入 從統一帳號 IAM 登入, MFA,較麻煩 登入 Google,直接使用
切換 Role 較直接, 但只有五個 動作多, 可以多個
認證管理:離職 關閉 IAM 權限 G Suite 統一管理
認證管理:增加 建立 IAM 帳號 G Suite 統一管理
—- ——–

Federated SSO 的重點在於 認證管理 (Authentication) 都可以擺在 G Suite 統一管理,人員的離職與異動都可以一次性的回收權限,不會造成資安漏洞。但是 授權 (Authorization) 還是在應用程式本身,也就是 AWS 的 IAM Role 要自行透過 Policy 管控。


延伸閱讀


Comments