GCP IAM 完全指南：身分管理與存取控制從入門到實戰

「你的雲端環境有多安全，取決於你如何管理『誰能做什麼』。」

你建好了第一台 VM（GCP-103）、設定好 VPC 網路（GCP-104），接下來最重要的問題是：誰可以存取這些資源？權限怎麼設定才不會出問題？

這就是 Cloud IAM（Identity and Access Management） 的核心任務。

IAM 是 GCP 所有安全架構的地基。不管你是在做個人專案，還是在管理企業的雲端環境，IAM 都是一定要搞懂的基本功。這也是 Associate Cloud Engineer 認證考試最常考的主題之一。

你將學到：

• ✅ GCP 資源層級與 IAM 政策繼承機制
• ✅ 三種身分類型：使用者、服務帳號、群組
• ✅ 三種角色類型：基本、預定義、自訂
• ✅ 服務帳號的正確使用方式與安全最佳實踐
• ✅ gcloud 指令實戰：授權、移除、查詢 IAM 政策
• ✅ IAM 條件（Conditions）入門
• ✅ ACE 考試重點提示

---

一、什麼是 IAM？三分鐘搞懂核心概念

IAM 的三個核心問題

每一次存取 GCP 資源，系統都要回答三個問題：

Who        can do      What        on Which resource?
(誰)        (做什麼)    (做什麼動作)  (在哪個資源)
Principal  Role        Permission  Resource

IAM 的工作就是管理這三者之間的對應關係。

最簡單的類比

把 GCP 想像成一棟辦公大樓：

• 主體（Principal）= 員工、訪客、清潔人員
• 角色（Role）= 員工證的權限等級（訪客、員工、主管、系統管理員）
• 資源（Resource）= 辦公室、會議室、伺服器機房
• IAM 政策（Policy）= 門禁系統的規則設定

當你說「小明可以管理 asia-east1 的 VM」，你就是在建立一個 IAM 綁定（Binding）：

小明（Principal）+ Compute Instance Admin（Role）+ Project A（Resource）

---

二、資源層級：IAM 政策如何繼承

GCP 資源的四層結構

GCP 所有資源都遵循以下層級關係：

Organization（組織）
    └── Folder（資料夾）
        └── Project（專案）
            └── Resource（資源）
                例如：VM、Cloud Storage、Cloud SQL

政策繼承規則

IAM 政策具有向下繼承的特性：

Organization 層級授予的權限
    ↓ 自動繼承到所有下層
    Folder 層級授予的權限
        ↓ 自動繼承到所有下層
        Project 層級授予的權限
            ↓ 自動繼承到所有下層
            Resource 層級授予的權限（僅限該資源）

有效政策 = 所有祖先層級政策的聯集（Union）

重要特性：子層級無法撤銷從父層級繼承的權限。如果你在 Organization 層給了某人 Viewer 權限，他在所有 Project 都有 Viewer 權限，就算 Project 層沒有授予他任何東西。

實務意義

場景	建議做法
全組織安全基線	在 Organization 層設定 DENY 規則
部門共用存取	在 Folder 層授予開發部門讀取權限
日常工作授權	在 Project 層管理個別成員權限
特定資源存取	在 Resource 層做細部控制

---

三、主體類型：誰可以被授予權限？

六種主體（Principal）

主體類型	說明	使用場景
Google Account	個人 Google 帳號（@gmail.com 或公司帳號）	開發者、管理員
Service Account	代表應用程式或工作負載的特殊帳號	VM、Cloud Run、GKE
Google Group	一組 Google 帳號的集合	部門授權、批次管理
Cloud Identity Domain	整個組織的身份管理系統	企業帳號管理
allAuthenticatedUsers	所有已登入 Google 帳號的使用者	⚠️ 慎用
allUsers	任何人（含匿名使用者）	公開資源（如公開網站）

使用 Google Group 管理批次權限

最佳實踐：不要一個一個授予個人帳號，而是：

1. 建立 Google Group（例如：dev-team@yourcompany.com）
2. 將群組成員加入/移除群組
3. IAM 只授權給群組，而不是個人

優點：當員工入職/離職時，只需調整群組成員，不需修改 IAM 政策。

# 授予 Google Group 權限
gcloud projects add-iam-policy-binding my-project \
    --member="group:dev-team@yourcompany.com" \
    --role="roles/compute.developer"

---

四、角色類型：能做什麼？

GCP 有三種角色類型，理解其差異是 ACE 考試的重點。

4.1 基本角色（Basic Roles）= 生產環境的大忌

基本角色是 GCP 最早期的角色設計，擁有極廣泛的權限：

角色	包含權限	生產環境
Viewer	所有服務的唯讀存取	⚠️ 謹慎使用
Editor	所有服務的讀取＋修改（含建立/刪除）	❌ 不建議
Owner	Editor + 帳務管理 + IAM 管理	❌ 絕對禁止

為什麼不建議使用基本角色？

基本角色一口氣涵蓋整個 GCP 幾千個 API 的存取權。你明明只想讓某人管理 Compute Engine，給他 roles/editor 卻等於連 BigQuery、Cloud SQL、Cloud Storage… 所有服務都一起開放給他了。

💡 考試提示：如果考題問「哪個角色符合最小權限原則」，答案永遠不是 Owner/Editor/Viewer。

4.2 預定義角色（Predefined Roles）= 生產環境首選

Google 幫每個 GCP 服務都準備了細粒度的預定義角色，目前已經超過 1,500 個，而且還在繼續增加：

roles/compute.admin          → Compute Engine 完整管理
roles/compute.instanceAdmin  → 僅管理 VM 執行個體
roles/compute.viewer         → Compute Engine 唯讀
roles/storage.admin          → Cloud Storage 完整管理
roles/storage.objectViewer   → 僅讀取 Storage 物件
roles/iam.serviceAccountUser → 使用服務帳號
roles/logging.viewer         → 查看 Cloud Logging

如何找到合適的預定義角色？

# 搜尋特定服務的所有角色
gcloud iam roles list --filter="name:compute" --project=my-project

# 查看角色包含的所有權限
gcloud iam roles describe roles/compute.instanceAdmin

4.3 自訂角色（Custom Roles）= 當預定義角色不夠用時

如果找不到任何預定義角色完全符合需求，就可以自己建立自訂角色：

# 建立自訂角色
gcloud iam roles create my-custom-role \
    --project=my-project \
    --title="My Custom Role" \
    --description="Limited VM management" \
    --permissions="compute.instances.start,compute.instances.stop,compute.instances.get" \
    --stage=GA

使用自訂角色的時機：

• 需要多個預定義角色的部分權限組合
• 企業安全政策要求比預定義角色更細的粒度
• 服務帳號需要最小化權限

缺點：自訂角色得自己維護，GCP 之後新增服務時，不會自動把新權限加進來。

---

五、服務帳號：應用程式的身分證

什麼是服務帳號（Service Account）？

服務帳號是一種特殊帳號，用來代表應用程式、VM 或自動化流程。

白話解釋：

• 你的程式需要存取 Cloud Storage，你不應該使用自己的 Google 帳號（你可能今天離職，明天程式就壞了）
• 你應該建立一個服務帳號，讓程式用這個帳號的身分來存取 Cloud Storage

服務帳號 vs 使用者帳號

比較項目	服務帳號	使用者帳號
用途	應用程式、自動化	真實的人
認證方式	金鑰或 Google 管理的憑證	密碼 + MFA
上限	每個專案預設 100 個	無限制
識別格式	NAME@PROJECT.iam.gserviceaccount.com	user@example.com

建立服務帳號

# 建立服務帳號
gcloud iam service-accounts create my-app-sa \
    --display-name="My Application Service Account" \
    --project=my-project

# 授予服務帳號權限（在特定資源或專案上）
gcloud projects add-iam-policy-binding my-project \
    --member="serviceAccount:my-app-sa@my-project.iam.gserviceaccount.com" \
    --role="roles/storage.objectViewer"

服務帳號金鑰：最常被誤用的功能

服務帳號有兩種金鑰類型：

金鑰類型	說明	建議
Google 管理的金鑰	GCP 自動管理、自動輪換	✅ 強烈推薦
使用者管理的金鑰	你下載 JSON 檔案，自己管理	⚠️ 謹慎使用

使用者管理金鑰的風險：

# ❌ 危險做法：下載金鑰 JSON 檔
gcloud iam service-accounts keys create key.json \
    --iam-account=my-app-sa@my-project.iam.gserviceaccount.com

這個 key.json 檔案就像一把萬能鑰匙：

• 如果不小心上傳到 GitHub → 任何人都能存取你的 GCP
• 需要手動輪換（Google 建議每 90 天）
• 很難追蹤誰有這把鑰匙的副本

✅ 正確做法：讓資源直接附加服務帳號

# 建立 VM 時指定服務帳號（不需要 JSON 金鑰）
gcloud compute instances create my-vm \
    --service-account=my-app-sa@my-project.iam.gserviceaccount.com \
    --scopes=https://www.googleapis.com/auth/cloud-platform \
    --zone=asia-east1-a

這樣一來，VM 要存取 Cloud Storage 時，GCP 會自動用附加的服務帳號身分去認證，完全不用碰 JSON 金鑰！

Workload Identity Federation：從外部系統存取 GCP

如果你的應用程式是跑在 GitHub Actions、GitLab CI、AWS 或內部伺服器上，那就可以用 Workload Identity Federation：

• 使用外部系統的身分（例如 GitHub Actions 的 OIDC token）
• 換取短期有效的 GCP 存取 token
• 完全不需要下載任何金鑰

這也是 2025 年最推薦的 CI/CD 整合方式，詳細設定可以參考 GCP 官方文件。

---

六、IAM 政策綁定實戰

gcloud 常用 IAM 指令

# 查詢專案的 IAM 政策
gcloud projects get-iam-policy my-project

# 授予使用者角色（在專案層級）
gcloud projects add-iam-policy-binding my-project \
    --member="user:alice@example.com" \
    --role="roles/compute.viewer"

# 移除使用者角色
gcloud projects remove-iam-policy-binding my-project \
    --member="user:alice@example.com" \
    --role="roles/compute.viewer"

# 授予服務帳號角色
gcloud projects add-iam-policy-binding my-project \
    --member="serviceAccount:my-sa@my-project.iam.gserviceaccount.com" \
    --role="roles/storage.objectAdmin"

# 授予 Google Group 角色
gcloud projects add-iam-policy-binding my-project \
    --member="group:dev-team@yourcompany.com" \
    --role="roles/compute.developer"

IAM 政策的 JSON 結構

IAM 政策是由多個「綁定（Binding）」組成的文件：

{
  "bindings": [
    {
      "role": "roles/compute.admin",
      "members": ["user:admin@example.com"]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "group:dev-team@example.com",
        "serviceAccount:app-sa@my-project.iam.gserviceaccount.com"
      ]
    }
  ],
  "etag": "BwXXXXX"
}

💡 etag 是版本控制標記，防止並發修改衝突。

---

七、IAM 條件（IAM Conditions）入門

IAM Conditions 讓你可以做屬性型存取控制（ABAC），在原本的角色授權上再加一層額外條件。

常見條件類型

條件類型	範例用途
時間限制	只在工作時間（週一至週五 9-18 點）允許存取
IP 位置	只允許公司 VPN 的 IP 範圍存取
資源類型	只允許存取特定服務的資源
資源名稱	只允許存取名稱以 prod- 開頭的資源
到期日期	臨時存取，自動在某日期後失效

設定有時效的臨時存取

# 授予 30 天有效的臨時 Viewer 權限
gcloud projects add-iam-policy-binding my-project \
    --member="user:contractor@example.com" \
    --role="roles/viewer" \
    --condition='expression=request.time < timestamp("2026-04-11T00:00:00Z"),title=temp-access,description=Temporary access for contractor'

條件使用 CEL（Common Expression Language） 語法撰寫。

---

八、IAM 最佳實踐清單

最佳實踐	說明
✅ 最小權限原則	只授予完成工作所需的最小權限
✅ 避免基本角色	生產環境一律使用預定義或自訂角色
✅ 使用 Google Group 管理	以群組授權，方便人員異動管理
✅ 服務帳號附加到資源	讓 VM/Cloud Run 直接使用附加的服務帳號
✅ 避免下載 JSON 金鑰	盡量使用 Google 管理的金鑰或 Workload Identity
✅ 啟用 Cloud Audit Logs	追蹤所有 IAM 變更記錄
✅ 定期稽核 IAM 政策	移除不再需要的授權（尤其是離職員工）
✅ 使用 IAM Conditions	為敏感操作加上時間或 IP 限制
❌ 不要使用 allUsers/allAuthenticatedUsers	除非確定要公開存取的資源
❌ 不要把 Owner 角色給太多人	至少保留 2 個 Owner，不超過 3 個

---

九、常見問題與陷阱

Q: 我刪除了使用者的角色，他還能存取資源嗎？

可能可以，如果：

1. 他還有其他角色（直接授予或透過群組繼承）
2. 上層（Folder/Organization）還有政策授予他權限

IAM 是加法、不是減法，有效權限是所有授予權限加起來的聯集。

Q: 服務帳號本身也需要 IAM 權限嗎？

是的！服務帳號有兩個面向：

1. 作為主體（Principal）：服務帳號可以被授予資源存取權（例如：讓這個 SA 能讀 Cloud Storage）
2. 作為資源（Resource）：誰可以使用（impersonate）這個服務帳號，本身也是一種 IAM 授權

# 允許使用者「使用」某個服務帳號
gcloud iam service-accounts add-iam-policy-binding \
    my-sa@my-project.iam.gserviceaccount.com \
    --member="user:bob@example.com" \
    --role="roles/iam.serviceAccountUser"

Q: 如何知道某個角色包含哪些權限？

# 查看角色的所有權限
gcloud iam roles describe roles/compute.instanceAdmin.v1

# 列出特定權限屬於哪些角色
gcloud iam list-grantable-roles //cloudresourcemanager.googleapis.com/projects/my-project

---

Organization Policies：IAM 之外的存取控制

IAM 管的是「誰可以做什麼」，而 Organization Policies 管的是「什麼事可以被做」，不管是誰都一樣。

IAM vs Organization Policy

面向	IAM	Organization Policy
控制對象	誰（身分）	什麼（行為/資源）
範例	「Alice 可以建立 VM」	「任何人都不能在海外區域建立 VM」
繼承方向	上層授權向下繼承	上層限制向下強制（子層不能放寬）
管理者	Project Owner / Admin	Organization Policy Administrator

常用 Organization Policy 約束

# 限制 VM 只能在台灣和日本區域建立
gcloud resource-manager org-policies allow \
  constraints/compute.locations \
  --organization=ORGANIZATION_ID \
  asia-east1 asia-northeast1

# 禁止建立外部 IP 的 VM（強制私有網路）
gcloud resource-manager org-policies enable-enforce \
  constraints/compute.vmExternalIpAccess \
  --organization=ORGANIZATION_ID

# 禁止建立服務帳號
gcloud resource-manager org-policies enable-enforce \
  constraints/iam.disableServiceAccountCreation \
  --project=my-project

ACE 考試常考的約束

約束	效果
compute.locations	限制資源可部署的區域
compute.vmExternalIpAccess	禁止 VM 使用外部 IP
iam.disableServiceAccountKeyCreation	禁止建立服務帳號金鑰
storage.uniformBucketLevelAccess	強制 Bucket 使用統一存取控制
compute.requireShieldedVm	強制使用 Shielded VM

ACE 考試重點：遇到「如何確保整個組織的 VM 都不能有外部 IP」的題目，答案是 Organization Policy（不是 IAM、不是防火牆）。Organization Policy 是強制性的，子專案無法覆寫。

---

十、ACE 考試重點提示

IAM 是 ACE 考試裡出題率最高的主題，下面整理幾種常見的考題類型：

類型 1：角色選擇

題目：你的開發團隊需要列出和存取 GCP 專案中的所有 VM，但不能建立或刪除。應授予哪個角色？

• ❌ roles/compute.admin（太多權限）
• ❌ roles/editor（基本角色，太多權限）
• ✅ roles/compute.viewer（只讀，符合最小權限）

類型 2：服務帳號設定

題目：你的 Cloud Run 服務需要讀取 Cloud Storage 的物件。最安全的做法是？

• ❌ 在程式碼中硬寫服務帳號金鑰
• ❌ 使用開發者個人帳號認證
• ✅ 建立服務帳號，授予 roles/storage.objectViewer，並讓 Cloud Run 使用此服務帳號

類型 3：政策繼承

題目：Alice 在 Organization 層有 Viewer 角色，在 Project A 有 Editor 角色，在 Project B 沒有任何角色。她對 Project B 有什麼存取權？

• ✅ 答案：Viewer（從 Organization 繼承）

類型 4：最小權限

題目：你需要讓一個自動化腳本能在 Cloud Storage 新增物件，但不能刪除。該用哪個角色？

• ❌ roles/storage.admin（可以刪除）
• ❌ roles/storage.objectViewer（只能讀取）
• ✅ roles/storage.objectCreator（只能新增物件）

---

十一、總結

IAM 的三個核心：

1. 主體（Principal）：誰（使用者、服務帳號、群組）
2. 角色（Role）：能做什麼（基本/預定義/自訂）
3. 資源（Resource）：在哪個層級（Organization/Folder/Project/Resource）

必記的最佳實踐：

• 永遠遵循最小權限原則
• 生產環境絕不用基本角色（Owner/Editor/Viewer）
• 應用程式用服務帳號，不用個人帳號
• 盡量不下載 JSON 金鑰，讓資源直接附加服務帳號
• 用 Google Group 管理批次授權

系列文章連結

• 📖 上一篇：GCP-104: GCP 網路基礎：VPC、防火牆與安全連線完全指南
• 📖 下一篇：ACE-206: GKE 與 Kubernetes 入門指南
• 📖 進階延伸：ACE-205: 企業級資安防護：GCP 安全架構與合規指南

---

延伸閱讀

• GCP IAM 官方文件
• IAM 角色完整列表
• 服務帳號最佳實踐
• Workload Identity Federation
• Cloud Audit Logs

---

🎓 本文是「GCP 精通之路」系列的 GCP-105 篇（入門篇），完整掌握 GCP IAM 基礎後，建議繼續學習 GCP 資料儲存策略。