身分與存取管理架構

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

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

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

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

先畫 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。

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

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，結果可能和預期不同。

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 評估，再規劃例外與修復。

人員的高權限應該有期限

把 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 本身變安全。

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 和網路控制都應立即移除。

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：

1. 建立 production 專用 workload identity pool／provider，驗證 GitHub OIDC issuer 和正確 audience。
2. Attribute mapping 包含 repository 與 branch／environment，授權只給 production environment 的 principal set。
3. 依 API 和管理模型，選 direct roles 或 impersonate 一個 deployment service account。
4. Deployment identity 只拿部署所需權限；runtime service account 另行管理，避免 CI 順便取得應用資料權限。
5. GitHub environment 設 protected branch、reviewer 和短效 token，不存 service account key。
6. 用 Audit Logs 驗證 token exchange、impersonation、revision deployment 和 IAM 變更都可追蹤。

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

本課檢查清單

• 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、資料邊界、敏感資料與軟體供應鏈。