[AWS] GWS User AD Join to Login AWS Account

最近剛好做到一個 Case,客戶是使用 GWS AD Account
有同時使用 GCP & AWS Service,但 IT 想統一 Account 去做管理

此步驟獻給類似需求情境的管理員們,同樣的 AzureAD 也是類似方法

Step1. 登入 要加入的 GWS Admin 管理介面

A. 選擇 Security > Authentication > SSO with SAML applications.

B. 拉到最下面, Download Metada

 Step2. 新增 IAM SAML Identity Provider 在 AWS Account

A. 首先登入想加入的 AWS Account 的 IAM Service

B. 並點選 IAM Service 下的 Identity Providers

C. 點選右邊 Add Provider

D. 點選 SAML

E. Provider Name (自行輸入,這邊是輸入 Join 的 GWS Domain)

F. Medata document (把剛剛在 GWS 端下載的檔案上傳上來)

G. 建置好後會取得 ARN 碼,這很重要 (複製下來貼旁邊)

Step3. 新增 AWS IAM Role 給予 透過 Identity Provider 的 GWS Account 權限 

A. 進入 IAM Console,選擇 Role > Create Role

B. 選擇 SAML 2.0 federation 下拉選單會帶出剛建立的 Provider

C. 然後點選 Allow programmatic and AWS Management Console Access

D. 點選 Next : Permissions 

E. 通過篩選把 AWS 預設 Role 帶出

F. 點選 左上方 放大鏡符號

G. 選取 Type > AWS managed – job function

H. 選擇 PowerUserAcces 後,點選下一步

I. Role details 輸入 Role 名稱 (GoogleSAMLPowerUserRole)

J. Description 輸入 Role 的大概內容 (GWS Login PowerUser Role)

K. 拉到最底,點選 Create Role

L. 建好後會看到你新建的 Role

M. 建置好後會取得 ARN 碼,這很重要 (複製下來貼旁邊)

N. 如需新增其他 Role ,重覆 Step 3 所有步驟即可即可

•  Role 1 GoogleSAMLPowerUserRole_Login
  • arn:aws:iam::174XXXXXXXXX:role/GoogleSAMLPowerUserRole_Login

 Step4. 給予 GWS User AWS IAM Role

A. 回到 GWS Admin Console

B. 點選 Directory > Users > More Option > Manage custom attributes

C. Category: AWS
        Description: Amazon Web Services Role Mapping
D. Custom fields, enter the following values:
        Name: AssumeRoleWithSaml
        Info type : Text
        Visibility : Visable to user and admin

        InNo of Values : Muti-value

        E. 回到 Users 端,選擇要加入的 User Account
        F. 點選 User > User Information

        G. 移到最下面有個 AWS 的,點選編輯

        H. 這時輸入最一開始拿到的 Identitiy Providers + IAM Role ARN

                這邊要特別注意,兩個組合再一起時,中間要用 , 分開

例如 : 

arn:aws:iam:: 174XXXXXXXXX::samlprovider/Dev.Cloud.XXX.tv ”,”arn:aws:iam:: 174XXXXXXXXX:role/GoogleSAMLPowerUserRole

I. 一行是一個 Role,假設你需要給予兩個或是更多的 Role

        請依照同樣方式 Identitiy Providers,IAM Role ARN

J. 假設你有多個 AWS Account 也可以依照前面步驟

        從 Step 2 開始,在另一個 AWS Account 用同樣步驟進行

        Step 3 在另一個 AWS Account用同樣步驟進行

        Step 4 開始,但只需要從 E 項目開始把其ARN 新增至 User Information內即可

K. 可看到我同時有兩個不同AWS Account的 Providers + Role ARN

Step 5. 在 GWS 端設定 SAML Application 給 AWS Login 

A. 進到GWS Admin 管理介面
B. 點選左邊 Apps > Web and Mobile apps 

C. 選取 Add custom SAML App 

 D. App name : 輸入 AWS Login (顯示在右上角選單內的名稱)

        APP Icon : 上傳一個圖示(顯示在右上角選單內的圖示)

E. 點選下一步

        Services Provider Details

• ACS URL : https://signin.aws.amazon.com/saml
• Entity ID : urn:amazon:webservices
• Name ID format : EMAIL
• Name ID : Basic Information > Primary email

F. 點選下一步

        在 Attributes 內新增

• 項次一 AWS 選擇 AssumeRoleWithSaml
• App attributes 輸入 https://aws.amazon.com/SAML/Attributes/Role
• 項次二 Base Information 選擇 Primary email
•  App attributes 輸入
•  https://aws.amazon.com/SAML/Attributes/RoleSessionName

    G.     按下 Finish 即完成

    H.     在來回到 Web and Mobile Apps 內,點選剛新增的 SAML APP

    I.     進入 User Access 把 Service Status 開城 ON for everyone

 J. 回到上一頁,按下 TEST SAML Login 就會出現,你配置的 Domain

或是點選右上角 APP 選單,往下滑也會有你建制的 SAML APP

K. 點選後就會出現 AWS Account and 你所賦予的 Role 權限

        此 Demo 建置了兩個 AWS Account 兩個 Role

L. 依據不同的權限,不同的帳號做登入測試

 

Step 6. 查找登入 Login Log 

A. GWS 端該如何查詢 Login Log

Console > Reporting > Audit and investigation > SAML log events

 B. AWS 端該如何查詢 Login Log

AWS Console > CloudTrail > Event history

 

 

 

[AWS] AWS Organizations 中 OU and SCP 權限配置邏輯

管理組織單位 (OU) : 可以使用組織單位 (OU) 將帳戶群組在一起，以單一單位的形式進行管理。這可大幅簡化帳戶的管理，可以將以政策為基礎的控制連接到 OU，而 OU 內的所有帳戶會自動繼承政策。您可以在單一組織內建立多個 OU，您也可以在其他 OU 內建立 OU。每個 OU 可以包含多個帳戶，而且您可以在 OU 之間移動帳戶。但是，OU 的名稱在父系 OU 或根中必須是唯一的。

服務控制政策 (SCP) : 服務控制政策 (SCP) 是一種組織政策類型，可用來管理組織中的許可。SCP 可集中控制組織中所有帳戶可用的許可上限。SCP 可協助您確保您的帳戶符合組織的存取控制指導方針。SCP 只有在啟用所有功能的組織中才能使用。

SCP 很重要的規則: 1. SCP 是定義權限的範圍並不是賦予權限 2. SCP 預設都是 Deny 的權限，除非明確 Allow 相關的權限 3. Deny 的權限高於 Allow 權限，並且 Deny 權限預設繼承到每一個 OU 和帳號上

Deny list strategy:

1. SCP 預設都是 Deny 的權限，所以在完全沒有附加任何的 SCP 時，在 root 和 OU上所有的權限都是Deny。
2. 當我們採取反向列表的方式來拒絕部分的權限時，預設都會在 root 和每一個 OU上都自動附加FullAWSAccess。
3. 因為 Deny 的權限高於 Allow 權限並且 OU 也會預設繼承 Deny 的權限，所以該 OU 的範圍內將只剩下預設 Deny 的權限和 DisableOrg，雖然有繼承 FullAWSAccess，但因為 OU 上明確的 Deny 權限將完全取代繼承下來的 FullAWSAccess。

Allow list strategy: 1. SCP 預設都是 Deny 的權限，所以在完全沒有附加任何的 SCP 時，在 root 和 OU 上所有的權限都是Deny。 2. 我們只需要允許 EC2 的權限，所以在 root 附加 FullEC2Access，這時候因為 OU 內預設是 Deny 的權限，即使 FullEC2Access 有繼承下來，但因為 OU 本身的權限優先於繼承下來的權限，所以這時候 OU 內還是Deny的狀態。 3. 當我們在 OU 上附加 FullEC2Access 後，因為明確的賦予 EC2 的權限，所以 OU 底下的帳號將可以擁有 EC2 的權限。 所以在 root 和每一個 OU 上的權限必須是明確附加的 Allow 權限，一旦沒有明確的附加 Allow 權限將會被 Deny權限給取代，所以繼承的 Allow 權限將被 OU 內預設 Deny 的權限給取代，以下是繼承的規則: 1. SCP 內如果定義 Allow 權限將需要在每一個需要這個權限的地方都附加上去。 2. SCP 內如果定義 Deny 權限，將可以發揮繼承的效果，在 OU 或子 OU 上發揮作用。