TL;DR
在 GCP 中，IAM (Identity and Access Management) 用於管理「誰」(Principal) 能對「某個資源」(Resource) 執行「什麼操作」(Role)。
IAM 透過角色綁定來授予權限，並遵循 GCP 資源的階層繼承關係。依需求選擇 Basic、Predefined 或 Custom Role，並遵守最小權限原則來確保安全性。
Identity and Access Management (IAM)
在 GCP 中，透過 IAM 機制來進行權限管理，避免 GCP 的資源被未經允許的用戶或服務訪問。
在 IAM 中，有三個重要的元件需要了解 :
- GCP Principals
- GCP Roles
- GCP Resources
IAM 的世界就是依靠這三個元件來形成規範 :
「誰 (GCP Principals)」 對於「某個資源 (GCP Resource)」擁有「什麼角色(GCP Role)」
Principal
Principal 在 GCP 的世界中，指的就是「可以造訪 GCP Resource 的主體」，這些主體可以是下列幾種類型 :
- Google Accounts
- Service Accounts
- Google Groups
- Google Workspace Accounts
- Cloud Identity Domains
allAuthenticatedUsersallUsers- Workforce Identity Pool 中的其中一個 Federated Identity。
- Workload Identity pool 中的其中一個 Federated Identity。
- GKE 中的 Pod 。
在 GCP 中，這些主體都會有一組 ID 來識別身份，稱為 Principal Identifier，不同類型的格式會稍有不同，可參閱 GCP 文件 - Principal Identifier。
GCP Role
在 GCP 的世界中，Permission 定義是否能對特定的 GCP Resource 進行特定的操作。
不論是透過 UI 或是 IaC (例如 Terraform) 操作元件，背後都是透過 API 進行操作，在互動的過程中，皆需要對應的 Permission。
而 API 和所需要的 Permission 通常都是一對一的關係，舉例來說：在呼叫 topics.publish() 失敗，代表目前的 Principal 並沒有 Pubsub.topics.publish() 的 Permission。
而 IAM 在管理 Permission 時，其實並不是直接把 Permission 賦予給特定的 Principal，而是將 Permission 封裝到特定的 “Role” 中，再將 “Role” 賦予給 Principal。綁定 Role 和 Principal 的行為稱為 “Role Binding”。
舉例來說，當我們要給予某個 User 「讀取」的 Permission，並不是直接將 Permission 給予 User，而是將「具有讀取 Permission」的 Role 賦予給該 User。
通常一個 GCP Role 中會包含一至數個不同的 Permission，可以將其劃分為幾種不同的類型 :
- Basic Role
- Predefined Role
- Custom Role
Type 1 - Basic Role
這是 GCP 最基本的 Role，有三種不同的類型 :
- Owner
- Editor
- Viewer
這些基本角色內蘊含了數千條 Google Service 的 Permission，在測試和實驗環境中，可以給予 Principal 此類權限來快速通關，但在正式環境中，並不建議直接使用 Basic Role，而是使用 Predefined Role 或是 Custom Role。
為什麼?
在雲端的世界中，基於安全性的考量，通常會遵循「最小權限原則」(The security principle of least privilege)，也就是 : 除了有申請開通的 Permission 外，預設什麼都不能做。
但是當我們將 Basic Role 授予 Principal 時，其中蘊含數以千計的 Permission 將會直接套用至 Principal 上，使得該 Principal 獲得大量 GCP Resource 的 Permission，這樣的行為與「最小權限原則」背道而馳。
Type 2 - Predefined Role
Predefined Role 相較於 Basic Role 來說，進行了更細緻的權限管理。
針對 GCP 的每一種 Resource，都會預先規劃好常見的角色，並在角色內給予適當的 Permission。
在官方文件中提出的範例是 : roles/pubsub.publisher，publisher 類型的角色基本上只會出現在 Pub/Sub 的情境中，針對這個情境的 publisher 會預先劃分所需的 Permission 在其中。
每一種 Resource 所預先劃分的 Predefined Role，可參考: GCP 官方文件 - Predefined Role List。
Type 3 - Custom Role
前述兩種類型的 Role 有不同的用途，Basic Role 涵蓋最廣、方便套用，但不適合使用在正式環境。而 Predefined Role 則可以根據 Principal 的目的，選定適合的角色來取得「合適」的權限。
如果上述兩種類型的情境都無法符合需求，例如組織有特定的權限規範時，也可以自行定義 Custom Role 來設定所需的 Permission，達成更細緻的權限管控。
IAM Allow Policy
IAM Allow Policy 具體來說，就是定義了 :
某個 GCP Role 被賦予給哪一個 GCP Principal
當某個 GCP Principal 打算造訪某個 GCP Resource 時，IAM 將會驗證此 Resource 的 IAM Policy，從中確認此 Principal 是否可以進行此操作。
具體來說：IAM Allow Policy 其實就是一系列的 Role Binding，將 1 ~ 多個 GCP Principal 與特定的 GCP Role 綁定，並將這些 IAM Policy 套用在特定的 GCP Resource 上。
GCP Resource 的階層與繼承關係
GCP Resource 之間是有階層關係的 :
- “Organization” 會是整體架構中的根節點 (Root)。
- “Folder” 可以是 “Organization” 或是 “Folder” 的子元素。
- “Project” 可以是 “Organization” 或是 “Folder” 的子元素。
- GCP Resource 必須隸屬於某一個 “Project”
掌握階層關係對於權限的配置會有很大的幫助，在設定 IAM Allow Policy 時，可以善用階層間的繼承關係 : 下層資源將會直接繼承上層資源的設定。
舉例來說：如果架構上是 :
當我們在 Folder 層級將 Compute Admin Role 給予 User ML 後，在 Project 層級不需要額外設定，User ML 仍然會取得 Compute Admin 的 Role。
在設計 IAM 架構時，較重要、通用性質的 Policy 可以善用繼承機制，設定在較上層的 Resource (例如上圖中的 “Level 1 - Organization”, “Level 2 - Folder”) 。若是較為客製化的設定，則可以定義在較下層的 Resource 層級，管理上會更有彈性。