身分與存取管理架構

權限問題要講得出完整句子

「他有 IAM，所以可以存取」這句話幾乎沒有除錯價值。真正有用的描述應該是：

哪一個 principal，在哪一個 resource 或 ancestor，透過哪個 role binding，取得哪個 permission；又被什麼 condition、deny 或其他邊界限制。

只要少一段，就可能誤判。接下來會用這個句型拆開 Google Cloud 的身分與授權架構。

先備能力：知道 project 與資源階層；不熟悉時先回 ACE 第二課。Role、permission 與 service account 的差別會在本課拆解。最後再用一組離線證據，驗證你能否追出授權來源、區分部署身分與執行身分，並提出範圍最小的修正。

先畫 Resource Manager 階層

Google Cloud 的主要資源階層是：

Organization → Folder → Project → Service-specific resource

• Organization 代表公司的治理範圍，常和 Cloud Identity 或 Google Workspace 建立關聯。
• Folder 用來表達治理邊界，例如事業群、環境或資料敏感度。
• Project 是 API、quota、billing attribution 與許多資源的管理邊界。
• Service-specific resource 才是 bucket、dataset、instance 等實際物件。

Allow policy 的 role binding 會沿階層向下繼承，而且子層不能用一個較小的 allow policy 抵銷祖先已授予的權限。若 organization 層給某群組廣泛角色，底下每個 project 都會承受這個 blast radius。

因此，高層級比較適合少量、真正跨組織的權限；日常操作權限盡量放在能滿足需求的最低層。階層應反映治理和風險，不必硬把公司組織圖原封不動搬進來。

flowchart TD
  O["Organization<br/>跨組織治理與少量共通權限"] --> F1["Folder<br/>事業群／環境／敏感度"]
  O --> F2["其他 Folder"]
  F1 --> P1["Project A<br/>API、quota、billing boundary"]
  F1 --> P2["Project B"]
  P1 --> R1["Bucket／Dataset／Instance"]
  P1 --> R2["其他 service resource"]
  AO["Organization allow binding"] -. "向下繼承" .-> F1
  AO -. "向下繼承" .-> P1
  AO -. "向下繼承" .-> R1
  AP["Project／resource allow binding"] -. "只增加該範圍權限" .-> P1
  N["子層較小的 allow policy<br/>不能抵銷祖先 grant"] -. "注意 blast radius" .-> R1

IAM allow：principal、role、resource

Principal

常見 principal 包括使用者、Google group、service account，以及 workforce／workload identity pool 中的 federated identity。管理人員權限時，通常綁 group 比綁個人更好維護，但還要有 group owner、成員審查和離職移除流程。

allUsers 代表任何人；allAuthenticatedUsers 的範圍也比「公司內所有人」大得多。若資源真的要公開，應把公開視為明確產品需求，搭配組織政策、暴露面掃描和應用層防護，而不是隨手加一個 principal。

Role

• Basic roles（Owner、Editor、Viewer）範圍廣，既有環境可能仍在使用。新設計通常先找 predefined role。
• Predefined roles 由 Google 維護，會隨服務演進；要 review 角色包含的 permissions，而不只看名稱。
• Custom roles 適合 predefined roles 仍過寬的情境，但團隊要負責 permission lifecycle、launch stage 與定期維護。

最小權限不表示每個人都要做一個 custom role。過多 custom roles 會難以理解和更新。先用工作職責分組，再判斷 predefined role 是否已足夠。

IAM Conditions

IAM Conditions 可以讓 allow role binding 只在條件成立時生效，例如 resource name、resource tag、請求時間，或在支援的 enforcement point 使用 access level。不是每個 permission 都支援每種 attribute，也不能把「來源 IP」當成所有 IAM policy 都能直接判斷的欄位。

設計條件前應查 IAM Conditions attribute reference，並用實際 API 呼叫測試。條件寫得很精巧、但服務不提供需要的 attribute，結果可能和預期不同。

條件只約束它所在的 binding。要合併祖先與本層的所有適用 allow bindings：只要其中一條授予所需 permission，且該條件成立或沒有條件，就有一條有效 allow。新增較窄或已過期的條件，不會取消另一條無條件 grant；最終仍要另外檢查 deny、PAB 與其他控制。可對照 IAM Conditions overview。

Deny、PAB 與 Organization Policy 不做同一件事

IAM deny policy

Deny policy 會在 allow policy 前評估，適合替特定 principals 和 permissions 建立拒絕護欄。不過要注意：

• 只有 支援的 permissions 能放進 deny policy。
• Deny conditions 目前只辨識 resource tag functions，不能直接照搬 allow condition 的時間或 access level 表達式。
• Deny 也沿資源階層繼承，錯誤規則可能影響大量專案。

如果需求是「任何一般管理員都不能刪除帶 prod tag 的支援資源」，可以評估 deny policy，並替 break-glass principal 設計審核過的 exception。先確認 delete permission 確實受支援。

Principal access boundary

Principal access boundary（PAB）限制 principal 最多能存取哪些資源範圍。它回答的是「即使收到 allow role，這個 principal 的可存取邊界到哪裡」。支援範圍與設定方式要依目前文件確認，適合需要替特定 workforce 建立資源上限的情境。

Organization Policy

Organization Policy 控制資源設定和可用行為，例如限制外部 IP、service account key 建立、可使用服務或資源位置。它不是授權系統：IAM 決定 principal 有沒有 permission；Org Policy 則讓某些配置即使有 permission 也不能建立。

Managed constraints 與 custom constraints 的資源支援不同，而且很多政策不會追溯修改既有資源。部署前應先用 dry-run（若 constraint 支援）、Policy Simulator 或測試 folder 評估，再規劃例外與修復。

flowchart TB
  Q["Principal 對 resource<br/>提出 operation"] --> K{"相關 policy 與身分<br/>證據是否完整？"}
  K -->|"否"| U["記為未知並補證據<br/>不能宣稱最終允許"]
  K -->|"是"| A{"所有適用 allow bindings 中<br/>至少一條包含 permission<br/>且無條件或條件成立？"}
  A -->|"否"| X["拒絕"]
  A -->|"是"| D{"適用的 deny 規則<br/>是否阻擋此請求？"}
  D -->|"是"| X
  D -->|"否"| P{"若有適用且受支援的 PAB<br/>resource 在允許範圍內？"}
  P -->|"否"| X
  P -->|"是"| I["IAM authorization 通過"]
  I --> O{"若要建立／修改配置，<br/>Org Policy constraint<br/>允許？"}
  O -->|"否"| X
  O -->|"是"| E["執行 operation<br/>留下 audit evidence"]

「沒有拿到 policy」和「已確認沒有適用 policy」不同。尤其只有 project 的 getIamPolicy 結果時，還不能推論祖先 grant、deny 或 PAB 不存在。若已有明確命中的拒絕規則，可以指出該阻擋；沒有找到拒絕證據，則不能反過來當成允許證明。Deny condition 為 true 或無法評估時的行為，也要依官方條件語意核對。

人員的高權限應該有期限

把 production admin 永久綁給個人，方便但難以證明最小權限。比較好的方向是：

• 日常身分只有唯讀或低風險操作權限。
• 需要高權限時，透過 Privileged Access Manager 或受控的 service account impersonation 申請短期存取。
• 高風險 entitlement 要有理由、核准、最長時間與 audit trail。
• Break-glass 帳號獨立保護、定期測試，使用後立即 review。

IAM Recommender 可以提供 role 使用資料與降權建議，但建議仍要由了解工作職責的人審核。沒有被觀察到的 permission，可能只是某個季度或災難復原時才使用。

工作負載不要帶長效 key

Google Cloud 內的工作負載

Compute Engine、Cloud Run 等服務通常讓工作負載使用 attached service account 和短效 token。GKE 則使用 Workload Identity Federation for GKE，讓 Kubernetes service account 與 IAM principal／service account 建立受控關係。不要把 service account JSON key 打進 image、Secret 或環境變數。

Google Cloud 外的工作負載

Workload Identity Federation（WIF）讓 AWS、Azure、地端、GitHub Actions、GitLab 等外部工作負載用原生 OIDC、SAML、AWS credentials 或其他支援身分交換 Google 的短效憑證。

目前有兩種主要授權方式：

1. Direct resource access：直接把 resource role 授給 workload identity pool 中的 principal 或 principal set。Google 一般建議能直接授權時優先使用。
2. Service account impersonation：外部 principal 先取得 impersonate 某個 service account 的能力，再以該 service account 存取資源。適合 API 相容性、既有權限模型或集中身分需求。

安全重點在 provider 信任和 attribute mapping：

• 驗證 issuer、audience 和 subject，不接受過寬的 token。
• 用 repository、branch、AWS role 等穩定 attribute 限縮 principal set。
• 不要把整個 pool 無條件授權給 production。
• Dev、staging、prod 可分 pool 或至少分 provider／attribute boundary。
• 稽核 STS exchange、impersonation 和最終 resource access。

WIF 消除的是長效 Google service account key，不會自動讓外部 IdP 本身變安全。

flowchart TB
  W["GitHub／GitLab／<br/>AWS／Azure<br/>外部 workload"] --> T["原生 OIDC／SAML／<br/>AWS token"]
  T --> V{"Provider 驗證<br/>issuer、audience、<br/>subject"}
  V -->|"不符"| X["拒絕 exchange"]
  V -->|"符合"| M["Attribute mapping<br/>repository、branch、role、environment"]
  M --> S["Security Token Service<br/>交換短效 federated credential"]
  S --> D{"授權模式"}
  D -->|"Direct access"| R["Pool principal／<br/>principal set<br/>直接取得 resource role"]
  D -->|"Impersonation"| I["只允許 impersonate<br/>指定 service account"]
  I --> R2["以 service account<br/>短效 token 存取 resource"]
  R --> A["統一寫入 Audit Logs"]
  R2 --> A

IAP：保護應用與管理入口

Identity-Aware Proxy（IAP）在支援的 HTTPS application 或 TCP administrative access 前做 authentication 和 authorization。常見用途有：

• 讓通過 IAM／context 條件的使用者存取內部 Web 應用。
• 使用 IAP TCP forwarding 連沒有 external IP 的 VM 上 SSH、RDP 或其他管理 port。

IAP 不是按下開關就會封住所有旁路：

• Backend 若仍有可直接到達的公開入口，流量可能繞過 IAP。
• IAP TCP forwarding 仍需 firewall 允許 IAP 的來源範圍到目標 port，並限制其他來源。
• 應用若信任 IAP 傳來的 identity header，要避免未經 IAP 的 client 自行偽造。
• 支援的 backend、load balancer 和功能要依當下 IAP documentation 確認。

Chrome Enterprise Premium 可搭配 Access Context Manager、Endpoint Verification、IAM Conditions 和 IAP，把裝置狀態、網路來源、身分與時間納入存取判斷。它適合 context-aware access，不代表所有傳統 VPN 和網路控制都應立即移除。

flowchart LR
  U["User／Administrator"] --> I["IAP<br/>authentication＋authorization"]
  C["Group、MFA、device posture<br/>access level、time"] --> I
  I -->|"通過"| L["Application<br/>Load Balancer<br/>或 TCP forwarding"]
  L --> B["Private／受限 backend"]
  I -->|"拒絕"| X["Denied access log"]
  D["Direct public IP／DNS<br/>其他 load balancer path"] -. "必須移除或封鎖" .-> B
  F["Firewall<br/>只允許 IAP／proxy 必要來源"] --> B
  H["Application 驗證<br/>IAP identity assertion"] --> B
  B --> A["Application-level authorization<br/>與 audit"]

Service account 的治理清單

• 每個 workload 使用用途清楚的 service account，避免跨系統共用。
• 不依賴 default service account 擁有什麼角色；明確設定需要的 roles。
• 限制誰能 attach、impersonate 或建立 service account key。能 impersonate 往往就等於能取得該帳戶權限。
• 用 organization policy 限制 key 建立／上傳，保留經審核的例外流程。
• 定期找出未使用的 service accounts、keys、role bindings 和跨專案 grants。
• 分開管理 service account 本身的 IAM policy，以及它對其他資源擁有的 permissions。

情境練習：外部 CI 部署 Cloud Run

假設 GitHub Actions 要部署 production Cloud Run。

先寫下你的做法：GitHub 的 workflow 怎麼換到 Google 身分、這個身分只該拿到哪些權限、事後怎麼稽核。寫完再展開對照。

這個設計最重要的不是「用了 WIF」，而是外部哪一個 workflow 能換到哪一個 Google 身分，以及那個身分到底能做什麼。

20 分鐘證據演練：條件過期了，為什麼還有權限？

以下全是本站編寫的封閉合成資料，不是實際專案、可用 token 或可直接套用的 policy。只需閱讀器與筆記，不用登入、部署或修改權限。先獨立填表，再展開答案。

先固定這一輪的範圍

本輪請求時間是 2026-10-29T10:00:00Z，目標是更新既有的 orders-api，使用的映像已存在，不含 build 或公開存取設定變更。

• 階層是 organizations/700001 → folders/800001 → projects/orders-prod，project number 為 123456789012。目標 service 為 projects/orders-prod/locations/asia-east1/services/orders-api。
• deploy@orders-prod.iam.gserviceaccount.com 是部署身分；runtime@orders-prod.iam.gserviceaccount.com 是同專案的執行身分，兩者不能互換。
• 下方列出本輪 principal 與待判斷 permission 的所有相關 allow bindings；沒有其他使用者／群組成員資格、custom role 或授權路徑。空 bindings 在本題表示已確認為空，不是沒有權限讀取。
• 安全管理員另已核對：本輪沒有適用的 deny 或 PAB 阻擋，Org Policy、服務代理、映像下載與其他部署必要檢查均通過。這些是本題明給的前提，不能在真實環境只憑 project allow policy 推論。
• ci-pool 啟用中，只有下方這一個啟用的 provider；token 簽章、有效期及 issuer 驗證已通過。下方 claims 是判讀摘錄，不是 JWT；尚待你檢查 audience、attribute condition 與授權。

本輪只追三段權限。roles/run.developer 含 run.services.update，不含 iam.serviceAccounts.actAs；roles/iam.workloadIdentityUser 讓符合的 federated principal 在指定 SA 上取得短效憑證；roles/iam.serviceAccountUser 含 iam.serviceAccounts.actAs，用來把指定 runtime SA 掛到 service。這不是三個角色的完整 permission 清單，也不能把「可取得 deploy SA token」當作「可掛任何 runtime SA」。實際部署需求可對照 Cloud Run roles與 Run Developer permission 清單。

證據 A：完整的相關 bindings

這是教材封裝：resource 標示 policy 的附加位置，policy 才是 allow policy 內容。所有 SA 都在 orders-prod。

[
  {
    "resource": "organizations/700001",
    "policy": {
      "bindings": [
        {
          "role": "roles/run.developer",
          "members": ["serviceAccount:deploy@orders-prod.iam.gserviceaccount.com"]
        }
      ]
    }
  },
  { "resource": "folders/800001", "policy": { "bindings": [] } },
  {
    "resource": "projects/orders-prod",
    "policy": {
      "version": 3,
      "bindings": [
        {
          "role": "roles/run.developer",
          "members": ["serviceAccount:deploy@orders-prod.iam.gserviceaccount.com"],
          "condition": {
            "title": "temporary-release",
            "expression": "request.time < timestamp('2026-10-29T09:00:00Z')"
          }
        }
      ]
    }
  },
  {
    "resource": "projects/orders-prod/locations/asia-east1/services/orders-api",
    "policy": { "bindings": [] }
  },
  {
    "resource": "projects/-/serviceAccounts/deploy@orders-prod.iam.gserviceaccount.com",
    "policy": {
      "bindings": [
        {
          "role": "roles/iam.workloadIdentityUser",
          "members": [
            "principalSet://iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/ci-pool/attribute.repository_id/203001"
          ]
        }
      ]
    }
  },
  {
    "resource": "projects/-/serviceAccounts/runtime@orders-prod.iam.gserviceaccount.com",
    "policy": { "bindings": [] }
  }
]

證據 B：provider 與兩次 CI claims

Provider 的 allowedAudiences 為空，使用預設規則：aud 必須是這個 provider 的完整 canonical resource name，可帶或不帶 HTTPS 前綴。這和 STS request 裡選定 provider 的 audience 欄位不是同一份 JSON；本題只列 IdP token 的 aud。

{
  "name": "projects/123456789012/locations/global/workloadIdentityPools/ci-pool/providers/github",
  "oidc": {
    "issuerUri": "https://token.actions.githubusercontent.com",
    "allowedAudiences": []
  },
  "attributeMapping": {
    "google.subject": "assertion.sub",
    "attribute.repository_id": "assertion.repository_id",
    "attribute.repository_owner_id": "assertion.repository_owner_id",
    "attribute.ref": "assertion.ref"
  },
  "attributeCondition": "attribute.repository_owner_id == '1342004' && attribute.repository_id == '203001' && attribute.ref == 'refs/heads/main' && google.subject == 'repo:cloudon-demo/orders:environment:production'"
}

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

ID 都是字串。Repository 名稱只出現在本題的額外 subject 限制；owner／repository 的數字 ID 也同時核對，避免僅依可被重新使用的名稱建立信任。若 repository 更名，subject 條件也需重新審查。本題採 SA impersonation；不表示所有整合都必須放棄 direct resource access。來源見 WIF deployment pipelines與provider audience 規則。

證據 C：同一次發布的錯誤與稽核摘錄

發布紀錄已用工作 ID、request ID 與時間範圍核對，以下兩筆屬於 CI-P 的同一次發布。lab_record_id 是教材標記；protoPayload 是依官方欄位語意編寫的精簡片段，不是完整實際日誌。此處已提供兩筆證據，不代表所有服務都預設記錄或一定包含相同欄位。

[
  {
    "lab_record_id": "E1-token-issued",
    "protoPayload": {
      "serviceName": "iamcredentials.googleapis.com",
      "methodName": "GenerateAccessToken",
      "authenticationInfo": {
        "principalSubject": "principal://iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/ci-pool/subject/repo:cloudon-demo/orders:environment:production"
      },
      "request": {
        "name": "projects/-/serviceAccounts/deploy@orders-prod.iam.gserviceaccount.com"
      },
      "status": { "code": 0 }
    }
  },
  {
    "lab_record_id": "E2-update-denied",
    "protoPayload": {
      "serviceName": "run.googleapis.com",
      "methodName": "google.cloud.run.v2.Services.UpdateService",
      "resourceName": "projects/orders-prod/locations/asia-east1/services/orders-api",
      "authenticationInfo": {
        "principalEmail": "deploy@orders-prod.iam.gserviceaccount.com",
        "serviceAccountDelegationInfo": [
          {
            "principalSubject": "principal://iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/ci-pool/subject/repo:cloudon-demo/orders:environment:production"
          }
        ]
      },
      "request": {
        "service": {
          "template": { "serviceAccount": "runtime@orders-prod.iam.gserviceaccount.com" }
        }
      },
      "status": {
        "code": 7,
        "message": "Permission 'iam.serviceAccounts.actAs' denied on service account runtime@orders-prod.iam.gserviceaccount.com."
      }
    }
  }
]

先交付判斷，再看答案

填一張表，每列寫出 principal、permission／檢查、resource、證據、結論：

1. CI-P 與 CI-F 能否通過 provider、再取得 deploy SA 憑證？只看到兩者同 repository 夠嗎？
2. 在 10:00Z，deploy SA 是否通過 run.services.update 的 allow 檢查？不要把整個部署結果與這一個 permission 混成一件事。
3. E2 卡在哪個 principal 對哪個 resource 的 permission？Runtime SA 是這次更新 API 的呼叫者嗎？
4. 為了只允許這個發布流程更新 orders-api 並掛上 runtime SA，應移除／新增哪些 binding？哪項安全證據仍不能從「沒有日誌」推論？

遷移題：拿走一份證據，答案會變嗎？

現在撤回本題「相關 policy 已完整取得」及「沒有適用 deny／PAB 阻擋」的前提。你只拿到 project 那條已過期的 binding；無法讀 organization／folder policy，安全管理員也只說「可能另有 deny」，尚未提供規則、scope 或支援的 permission。

你能否判定 deploy SA 的 run.services.update 一定允許或一定拒絕？先寫下結論與要補的證據，再展開。

課後檢查

往下看重點之前，先試著回答這幾題；答不出來，括號裡是該回去重讀的那一節。

• Organization 層已經給了某個群組廣泛角色，能不能在 project 層用較小的 allow policy 抵銷？（回〈先畫 Resource Manager 階層〉）
• Deny policy、PAB 和 Organization Policy 各自限制什麼？（回〈Deny、PAB 與 Organization Policy 不做同一件事〉）
• 開了 IAP 之後，還要補哪些設定才不會被繞過？（回〈IAP〉）
• 一條過期 binding 為什麼不能證明沒有權限？取得 deploy SA token 為什麼仍可能無法部署？（回〈20 分鐘證據演練：條件過期了，為什麼還有權限？〉）

本課重點

• Allow policy 向下繼承；子層 policy 不會抵銷祖先的 allow binding。
• IAM Conditions、deny policy、PAB 與 Organization Policy 的控制對象不同。
• Deny 只支援部分 permissions，deny condition 也有 attribute 限制。
• 人員高權限盡量改成有期限、可核准、可稽核的存取。
• WIF 可 direct access，也可 impersonate service account；兩者都要限制外部 attribute。
• IAP 要搭配 backend、firewall 和 direct-access 封鎖，才能避免旁路。
• Service account key 是例外，不是工作負載認證的預設選項。

延伸閱讀

• IAM overview
• Workload Identity Federation
• Organization Policy overview
• Chrome Enterprise Premium access protection

下一步

下一課會把焦點從「誰能存取」移到「資料本身怎麼保護」，包含加密金鑰、secret、資料邊界、敏感資料與軟體供應鏈。