理解 Google Cloud IAM (身分與存取管理)
身分與存取管理 (Identity and Access Management, IAM) 是 Google Cloud 的安全核心。對於 Associate Cloud Engineer (ACE) 考試來說，IAM 不僅僅是「誰能進入系統」，更重要的是「誰能在特定的資源上執行什麼動作」。IAM 讓管理員能以細粒度 (fine-grained) 的方式控制存取權限，確保系統的安全與合規性。
在 GCP 中，IAM 的基本邏輯可以簡化為一個公式：「誰 (身分) + 能做什麼 (角色) + 對哪個資源 (資源)」。這三個要素構成了 IAM 政策 (Policy)。
白話文解釋
為了讓初學者更容易理解 IAM 的運作，我們可以使用以下三個類比：
1. 辦公大樓的門禁卡系統 (瑞士刀類比)
想像一棟現代化的辦公大樓（GCP 資源）：
- 身分 (Identity)：你是誰（員工、訪客、清潔工）。
- 角色 (Role)：你的職位賦予你的權限。例如，「安全主管」角色可以進入所有房間（基本角色），而「工程師」角色只能進入機房（預定義角色）。
- 權限 (Permission)：門禁卡上的具體編碼，例如「刷卡開門」或「調整冷氣溫度」。
如果你只是拿著一張普通門禁卡（基本角色），你可能能進出大樓，但如果你需要更專業的功能（如修理伺服器），你需要特定的工具包（預定義角色）。
2. 圖書館的管理系統 (圖書館類比)
想像一個大型圖書館：
- 組織 (Organization)：整座圖書館系統。
- 專案 (Project)：特定的藏書區（如「科學區」）。
- 資源 (Resource)：具體的一本書或一台電腦。
- 角色 (Role)：
- 管理員 (Admin)：可以借書、買書、丟書、甚至改建圖書館。
- 讀者 (Reader)：只能看書，不能帶走或修改。
- 特約研究員 (自定義角色)：可以進入禁書區，但不能借出。
權限是繼承的：如果你是科學區的管理員，你自然擁有科學區內所有書籍的管理權限。
3. 開書考試的准考證 (開書考試類比)
在一場大型考試中：
- 身分：考生。
- 政策：准考證上寫明的規則。
- 繼承：如果考場規則規定「所有考場禁止交談」，那麼無論你在哪一個教室（專案/資源），這條規則都適用。
- 角色：監考老師有「監考」角色，他可以走動（檢視）和沒收手機（刪除），而考生只有「作答」角色（執行）。
IAM 的三個組成部分：誰、能做什麼、對哪個資源
IAM 的運作圍繞著三個主軸：
1. 誰 (身分/成員)
在 GCP 中，成員 (Members) 指的是可以被授予資源存取權限的實體。這包括：
- Google 帳戶：個人 Gmail 帳戶。
- 服務帳戶 (Service Accounts)：供應用程式或虛擬機使用的非人身分。
- Google 群組：一組 Google 帳戶的集合，便於批次管理。
- Cloud Identity/Google Workspace 網域：整個公司的網域。
2. 能做什麼 (角色/權限)
角色是一組權限的集合。權限通常以 service.resource.verb 的形式呈現，例如 compute.instances.start。你不會直接把權限給人，而是將人綁定到「角色」上。
3. 對哪個資源 (資源)
這是權限作用的對象，例如一個特定的 VM 實例、一個 Cloud Storage 儲存桶或一個專案。
IAM 成員類型 (身分)
了解成員類型對於 ACE 考試至關重要，因為考試常考「如何最有效地管理大量使用者」。
Google 帳戶與群組 (Google Accounts & Groups)
- Google 帳戶: 適用於個人開發者或小型團隊。
- Google 群組: 將角色授予群組而非個人，是管理權限的最佳實踐。
不要將權限直接授予個人，而是授予 Google 群組，然後將個人加入群組。這樣當人員異動時，你只需要調整群組成員，而不需要修改每個資源的 IAM 政策。同時建議在資源階層的最低層級（例如 bucket 或 project，而非 organization）授予角色，以維持最小爆炸半徑。 Source ↗
服務帳戶 (Service Accounts)
這是應用程式的身分。例如，運行在 Compute Engine 上的程式碼需要存取 Cloud Storage，你應該為 VM 分配一個具有正確權限的服務帳戶，而不是在程式碼中硬編碼 API 金鑰。
Google Workspace 與 Cloud Identity
這允許你管理整個網域下的使用者。如果員工離職，關閉其網域帳戶會自動撤回其在 GCP 中的所有存取權限。
深入理解 IAM 角色
GCP 提供三種類型的角色，其靈活性與管理複雜度各不相同：
1. 基本角色 (Basic Roles / Primitive Roles)
這是 GCP 早期提供的角色，權限非常大且粗略：
- 檢視者 (Viewer,
roles/viewer): 唯讀權限。 - 編輯者 (Editor,
roles/editor): 包含檢視者權限，加上修改資源的能力（但不包括管理身分）。 - 擁有者 (Owner,
roles/owner): 包含編輯者權限，加上管理身分與計費的能力。
考試陷阱：在生產環境中應避免使用基本角色，因為它們違反了「最小權限原則」。除非是開發測試環境，否則建議使用預定義角色。 Source ↗
2. 預定義角色 (Predefined Roles)
Google 為特定服務建立的角色，提供更精細的控制。例如：
roles/storage.objectViewer：只能看儲存桶裡的檔案。roles/compute.instanceAdmin.v1：可以管理 VM 但不能動網路。
3. 自定義角色 (Custom Roles)
如果預定義角色仍無法滿足需求，你可以自己挑選權限組合。
自定義角色不能跨專案使用（除非在組織層級定義），且需要持續維護，因為 Google 更新服務時不會自動更新自定義角色的權限。 Source ↗
IAM 政策結構與綁定 (Policy Structure and Binding)
IAM 政策是一個 JSON 或 YAML 文件，定義了「誰擁有什麼角色」。
政策綁定 (Policy Binding)
一條綁定 (Binding) 包含：
- 成員 (Members): 一個或多個成員。
- 角色 (Role): 一個特定的角色。
- 條件 (Condition, 選用): 例如「只在特定的時間段內有效」。
IAM 政策是資源上的屬性。當你檢查權限時，GCP 會查找該資源及其所有父級資源上定義的所有政策。 Source ↗
資源階層與政策繼承
這是 ACE 考試中最常見的考點之一。權限是繼承的且只能增加不能減少。
繼承機制 (Inheritance Mechanics)
- 如果你在 組織 (Organization) 層級授予了
檢視者角色，該使用者將成為該組織下所有資料夾、所有專案、所有資源的檢視者。 - 子資源繼承父資源的所有政策。
- 不能撤銷繼承的權限：如果父級給了
編輯者，你在子級給檢視者是沒用的，該使用者依然擁有編輯者權限。
有效政策 = (在資源上設定的政策) + (從階層中所有祖先繼承的政策)。 Source ↗
ACE 情境若主體 (principal) 已從組織層級繼承 roles/editor，唯一能阻擋該有效權限的方式是 Deny Policy，而不是在專案層級加上反向的 Allow binding。實務上需搭配 IAM Conditions（時間、IP、資源名稱）與 Policy Troubleshooter，才能精準判斷請求被允許或拒絕的原因。
Source ↗
最小權限原則 (Principle of Least Privilege, PoLP)
最小權限原則是 GCP 安全的黃金律。
- 定義：只給予使用者完成其工作所需的最小權限集。
- 應用：
- 優先使用預定義角色而非基本角色。
- 在資源層級的最低層次授予權限（例如在儲存桶層級而非專案層級）。
- 頻繁審核權限。
使用 gcloud CLI 管理 IAM
身為雲端工程師，你必須熟悉以下 CLI 指令：
查看政策
gcloud projects get-iam-policy PROJECT_ID
增加綁定
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:[email protected]" \
--role="roles/viewer"
移除綁定
gcloud projects remove-iam-policy-binding PROJECT_ID \
--member="user:[email protected]" \
--role="roles/viewer"
ACE 考試的 IAM 最佳實務
- 使用群組管理使用者：減少重複勞動。
- 謹慎使用服務帳戶金鑰：優先使用自動管理的服務帳戶身分（例如 VM 上的預設服務帳戶或 Workload Identity）。
- 區分環境：不同的專案/資料夾對應生產 (Prod)、測試 (Stage)、開發 (Dev) 環境，並套用不同的 IAM 策略。
- 定期審計：使用 Cloud Audit Logs 查看誰在何時做了什麼。
常見 IAM 情境與故障排除
情境一：使用者無法建立 VM，即便擁有 roles/compute.instanceAdmin
- 可能原因：使用者可能沒有在該專案中被授予「使用服務帳戶」的權限 (
roles/iam.serviceAccountUser)。建立 VM 時需要身分去執行。
情境二：如何讓開發者只能在白天存取資源？
- 解決方案：使用 IAM 條件 (IAM Conditions)，在綁定角色時加入時間限制條件。
常見問題 (FAQ)
問：我可以直接把權限 (Permission) 給使用者嗎？ 答：不行。你必須把權限包裝在角色 (Role) 裡，然後把角色給使用者。
問：如果一個使用者在專案層級是檢視者，在儲存桶層級是編輯者，他最後是什麼權限？ 答：他是編輯者。權限是相加的 (Additive)。
問：自定義角色可以包含所有權限嗎？ 答：大部分可以，但有些敏感權限（如修改 IAM 政策本身的部分權限）不允許包含在自定義角色中。
問：服務帳戶 (Service Account) 跟使用者帳戶有什麼不同？ 答：服務帳戶不屬於特定人類，它沒有密碼，而是使用金鑰對 (Keys) 進行驗證。
問：刪除專案後，對應的 IAM 政策會怎樣？ 答：專案刪除後，該專案上的所有 IAM 政策也會一併消失。
ACE 總結清單
- 清楚區分基本角色、預定義角色、自定義角色。
- 理解資源階層中的權限繼承邏輯（向下流動）。
- 知道如何使用
gcloud增加或移除 IAM 綁定。 - 熟記最小權限原則的具體應用場景。
- 理解服務帳戶 (Service Account) 的用途與安全性。