IAM 是什麼？GCP Cloud IAM 介紹

IAM 是什麼？Cloud IAM 功能為何？

IAM（Identity and Access Management）意思是「身分識別與存取管理」。而 Cloud IAM 是 Google Cloud（原 GCP）的資源權限管理服務，管理者透過設定 Cloud IAM，告知 GCP 使用者擁有什麼身份，還有他被允許在 GCP 的哪一項資源（Resource）中可以進行什麼操作。

簡單來說，Cloud IAM 的基本概念，可以解釋成：

什麼「人」，可以對什麼「資源」，做什麼「事情」

IAM 教學 – Cloud IAM 授權設定

根據前一段提及的概念，假設有一位開發工程師 Eric ，需要在您管理的 GCP Project 裡取得 Compute Engine 的 Compute Admin 權限，使用 Cloud IAM 進行授權時，須分別針對「人」、「資源」和「事情」這三項內容進行以下設定。

Who（Identity）設定

首先，我們取得這位使用者的信箱，作為辨識使用者身份的依據，因此 Eric 若要進入 GCP Project，就必須使用 snowyeric@gmail.com 這個電子郵件才能登入您管理的專案。

在 Cloud IAM Console 操作時，我可以在 Cloud IAM 的介面上點選 +ADD 的按鍵，把 Eric 的信箱加入 New principals 欄位。

Resource 設定

第二步，設定 Eric 的資源使用範圍，在 Select a role 的選單裡，選擇 Compute Engine，規範這個帳號只能使用 GCP Project 中的 Compute Engine 服務。

Do What（Roles）設定

選定授權資源後，就要設定使用者可以對資源做什麼事。所以，依照範例的情境，我們授權 Compute Admin 這個角色，這樣，Eric 在進入您的 GCP Project 以後，就可以對 Compute Engine 裡面的資源進行管理以及操作，如下圖所示，設定儲存後，Eric 就能透過他的電子郵件帳號進入 GCP Project， 管理 Compute Engine 裡面的資源。

不過，在管理專案權限時，組織裡面的人數越多、參與專案的組成人員越複雜，設定權限的方式就要更加的細緻；誰可以做什麼，誰不能做什麼，都要事先做好規劃並套用適當的 Cloud IAM 設定，才能有效地對使用者權限進行管理，以下我們將進一步說明 Cloud IAM 的重要概念。

IAM 重要概念 – Cloud IAM 6 大要素

Identity

Identity 代表允許被 Cloud IAM 授權的 Email 帳號身份。

這些帳號身份包含以下五個種類：

1. Google Account： 通常是一個以 @gmail.com 結尾的電子郵件帳號，它可以代表管理員或是開發者，Google 也允許您用個人的 Email 帳號註冊一個 Google Account。

2. Service Account：一組提供給應用程式，或是虛擬機的帳號，有別於提供給 End User 的帳號，Service Account 的用途為提供應用程式在 GCP 上面執行時所需的權限。

3. Google Group： Google Group 指的是多個 Google Accounts 或是 Service Accounts 的集合。 每一個 Google Group 都有唯一的一個電子郵件帳號。Google Groups 的用途是讓管理者可以透過一個帳號直接對集合當中的帳號進行授權或是權限的調整，當有新的使用者（或是 Service Account）必須取得與群集相當的權限時，只要將它加入到 Google Group 即可獲得授權。不過要特別注意，Google Group 的電子郵件是無法作為 GCP 的登入帳號使用的。

4. G Suite Domain： G Suite Domain 是整個代表著一整個創建在組織 G Suite 帳號下的虛擬群組，跟 Google Group 相同的地方是，G Suite Domain 方便管理員對群組帳號進行管理，但是 G Suite Domain 這個帳號本身同樣無法作為登入使用 GCP 的帳號。

5. Cloud Identity： 功能跟 G Suite Domain 類似， 差別是 Cloud Identity 可以讓沒有使⽤ G Suite 的企業或公司將⾃⼰的 Domain（如： example.com.tw） 註冊⾄ GCP 的 Organization，以便管理員在 Cloud IAM 管理 Domain 底下的帳號。關於 Cloud Identity Free 的帳號註冊教學，可以參考這篇文章。

Resource

Cloud IAM 針對 GCP 的資源提供精細的授權功能，當使用者需要特定的資源權限時，我們就可以使用 Cloud IAM 把該資源授權給使用者。

Cloud IAM 中的資源可以有哪些分類？依照授權的範圍大小，大可至一整個 Organization，如果細分的話則可以將 GCP 當中眾多服務切分開來做授權。例如：GCP Project 底下的 Compute Engine 跟 BigQuery 就可以當作 Cloud IAM 獨立授權的資源。

Permission

在介紹過 Identity 跟 Resource 以後，我們已經把整個 Cloud IAM 裡面的核心概念「誰可以對什麼資源做什麼事情」解釋了三分之二，接下來的 Permission，就是解釋使用者可以對資源做什麼操作。以下是Cloud IAM 的 Permission 正式的文字表示法範例：

pubsub.subscriptions.consume

在設定 Cloud IAM 的時候，我們不會直接把 Permission 授權給使用者；取而代之的是授權給使用者包含一到多個 Permission 的 Role。

Roles

Roles 是由一個到多個的 Permission 組合而成的角色，Permission 決定了使用者可以對資源進行哪些操作，所以當管理者將 Role 授權給使用者的同時，也授權了角色當中包含的所有 Permission。

在 Cloud IAM 的 Roles 主要的角色有三種：

• Basic Roles： 在 Cloud IAM 產生前就已經存在 GCP 上的角色，分為 Owner, Editor 跟 Viewer 。其中 Owner 的角色涵蓋 Editor 以及 Viewer 的權限，對資源享有所有的存取權，Editor 的角色涵蓋了 Viewer 的角色權限，可以修改已經存在的資源。而 Viewer 只能夠對資源進行檢視。

• Predefined Roles： 由 Cloud IAM 預設比 Basic Role 更精細（或說，範圍更小）的授權角色，主要是針對特定的資源去做權限設置。 舉例來說：Pub/Sub Publisher（roles/pubsub.publisher） 這個 Predefined Role 僅提供給使用者產生訊息到 Pub/Sub topic 的權限。而 Storage Object Creator 這個角色（roles/storage.objectCreator），可以提供使用者產生 Cloud Storage 的 Object 的權限，但無法檢視、刪除或是覆寫 Bucket 中的 Object。

• Custom Roles： 如果 Cloud IAM 預定的角色無法滿足管理者的授權需求，GCP 提供客製化的角色，你可以將多個 Permission 授與一個 Custom Role，這個角色功能可以彌補 Predefined Role 的不足。

IAM Policy

接下來，當我們制定好角色以後，要如何將它授權給使用者？我們需要使用 IAM Policy。IAM Policy 會針對整個 Organization 中的資源做具體的存取權限規範。請參考下圖了解 IAM Policy 的使用概念。

從圖中我們可以了解到，Policy 是一至多個 Binding 的集合，在每個 Binding 中，管理者可將一個或多個使用者（Identity）授權給一個單獨的 Role。如上圖的範例所示，管理者透過 IAM Policy 制定出兩個 Binding。

第一個 Binding 授權 compute.imageUser 這個 Role 給一個 Google Account 跟一個 Service Account 的 Identity；第二個 Binding 授權 compute .instanceAdmon.v1 這個 Role 給 G Suite Domain Account 跟 Google Group 這兩個 Identity。當上述的 Identity 進入到 Organization 去存取資源時，Cloud IAM 就會查看 Identity 的 Policy 是否對欲存取的資源擁有足夠的權限。

IAM Resource Hierarchy

最後介紹 Cloud IAM 的 Resource Hierarchy。在 GCP 上，所有的資源都是以階層的方式進行組織，由上到下可以分為：

1. Organization： 根節點，資源的最上層
2. Folder： Organization 的子項目
3. Project： Organization 或是 Folder 的子項目
4. Resource： Project 下面的子項目

藉由下面這張階層圖，我們會進一步了解 Resource Hierarchy 。

管理者可以對 Resource Hierarchy 中的任意一個層級（Organizaiton. Folder. Project. Resource）設定 IAM Policy，而資源層級之間都有由下而上的繼承性。資源的有效政策，指的是在某項資源設置的 Policy 與該資源繼承資源層級中更高層級而來的 Policy 的集合。

有效政策的繼承是具有傳遞性的，因此，Resource 會繼承 Project 層級的 Policy，Project 會繼承 Folder 層級的 Policy，而 Folder 會繼承 Organization 層級的 Policy。舉個例子，當管理者透過 Cloud IAM 將某位使用者授與 Organization 的 Editor 的角色權限，這位使用者就會同時享有 Organization 下任何 Project 的 Editor 權限。 

另一個關於 Resource Hierarchy 值得一提的概念是，子資源的 Policy 會隨著繼承的資源層級的 Policy 產生變化。舉例來說，有個 GCP 的 Organization 管理者將資源層級下的 Project A 中的 compute.viewer 角色權限授與 engineer@example.com ，不過在 Project B 裡面， engineer@example.com 這位使用者是擁有 Project Owner 這個 Policy，代表 engineer@example.com 這位使用者對 Project A 的 Compute 資源僅享有檢視的權限。

但假設，當管理者將 Project A 裡面的一台 VM 「my_instance」 搬到 Project B 底下 ，這台 VM 的 Policy 就會繼承從上一層資源沿襲而來的 Policy。而由於 engineer@example.com 這位使用者是 Project B 的 Project Owner，他對 my_instance 這台 VM 的權限就會從 Viewer 轉為 Owner。

以上就是 GCP Cloud IAM 的重要概念介紹，希望這篇文章可以幫助您更了解什麼是 Cloud IAM。大家對文章內容有任何問題都歡迎直接留言詢問，想更了解GCP 或有導入的相關需求也歡迎直接聯繫我們喔。

▋延伸閱讀：

・【GCP 資安】4大服務面向與企業常用2大架構
・比 VPN 連線、跳板機更方便！利用 Cloud IAP 快速建立遠端安全連線
・AD 帳號登入 GCP 方法攻略！用 Cloud Identity 與 GCDS/PS 移轉帳號資料
・AD 帳號登入 GCP 方法攻略！運用 ADFS 作為 GCP 外部身分認證
・[GCP DDoS 大作戰] 如何設定 Google Cloud Armor 阻擋來自某些國家的 IP