在雲端基礎設施的維運中，讓外部系統（如 CI/CD 工具、第三方服務或其他雲端平台）存取 Google Cloud Platform (GCP) 資源時，最常見的做法是建立一個服務帳號 (Service Account)，下載 JSON 格式的金鑰檔案，並將其儲存在秘密管理工具或環境變數中。然而，這種依賴長期金鑰 (Long-Lived Credentials) 的模式潛藏巨大的安全風險：金鑰一旦洩漏，攻擊者將擁有永久存取權限，直到金鑰被手動撤銷。此外，為了安全而設定的金鑰到期日，會帶來沉重的維運壓力，工程師必須定期更換金鑰並同步更新所有使用該金鑰的系統，這常導致團隊為了方便而選擇不設定到期日，進而惡化安全漏洞。
為了徹底解決金鑰管理壓力，GCP 推出了 Workload Identity Federation (WIF)，這是一種將「管理秘密」轉化為「配置信任關係」的身份認證機制。WIF 允許外部工作負載使用其原生身份令牌 (Token) 向 GCP 證明身份，並換取一個短暫的 GCP 存取令牌，從而實現無需儲存任何長期金鑰的認證流程。
Workload Identity Federation 的核心運作邏輯在於建立一套信任鏈。與其將金鑰交給外部系統，開發者只需在 GCP 端定義「我信任誰」以及「在什麼條件下信任」。其架構由三個核心元件組成：首先是 Workload Identity Pool (工作負載身份池)，這是一個邏輯容器，用於將相關的外部身份配置分組。其次是 Provider (提供者)，它是實際的連接器，定義了令牌的來源（如 GitHub 或 AWS）、如何驗證令牌的真實性，以及如何將外部身份的屬性對應到 GCP 可識別的屬性。最後是 Service Account Binding (服務帳號綁定)，當外部身份通過驗證後，會被綁定到一個特定的服務帳號，從而暫時繼承該帳號的 IAM 權限。
針對不同平台的實作路徑有所差異。對於支援 OpenID Connect (OIDC) 的平台（如 GitHub Actions 或 Harness），流程相對標準。平台在執行工作流時會生成一個由其簽名的短暫 JWT 令牌，GCP 的 OIDC 提供者會透過 Issuer URL (發行者網址) 獲取公鑰來驗證令牌，並利用 Attribute Mappings (屬性對應) 將令牌中的儲存庫名稱或組織 ID 轉譯為 GCP 屬性。而 Attribute Conditions (屬性條件) 則是至關重要的安全閘門，開發者必須使用 Common Expression Language (CEL) 語法明確限制僅允許特定儲存庫或帳號通過，否則任何持有該發行者有效令牌的身份都能通過驗證。
對於不使用 OIDC 的 AWS 工作負載，WIF 則採用另一套機制。AWS 實例（如 Lambda 或 EC2）會使用 AWS STS (Security Token Service) 的 AssumeRole 機制生成身份證明。當 GCP 收到 AWS 的認證封包後，並非直接信任，而是由 GCP 代表該工作負載向 AWS STS 發起 GetCallerIdentity 請求。AWS 會驗證簽名並回傳該身份所屬的 AWS 帳號 ID 與 IAM 角色。GCP 隨後比對此回傳結果是否與配置的 AWS Provider 相符，驗證通過後才核發 GCP 令牌。
在實務部署上，將 WIF 規模化推廣至組織內部時，採取「新案強制執行」而非「舊案全面遷移」是更務實的策略。由於舊有金鑰數量龐大且使用處分散，強行遷移可能導致不可預期的服務中斷。透過在建立新 GCP 專案時強制要求使用 WIF，可以將安全風險控制在一個固定且逐漸縮小的範圍內，避免問題持續擴大。
此外，在權限授予模式上，開發者需在 Direct Resource Access (直接資源存取) 與 Impersonation (身份模擬) 之間做出選擇。雖然 Google 建議直接將權限授予聯邦身份，但使用服務帳號進行身份模擬在大型組織中更具優勢。首先，透過服務帳號可以統一管理跨專案的存取權限，在人員離職或權限撤銷時，只需在單一服務帳號上操作，而非在每個資源上搜尋綁定關係。其次，某些特定功能（如 Cloud Storage 的簽署 URL）必須依賴服務帳號的私鑰簽名能力，直接存取模式無法支援此需求。
儘管 WIF 大幅降低了金鑰洩漏風險，但並非完全沒有風險。短暫令牌（通常有效期一小時）若在有效期內被截獲，依然可能被利用。因此，實務上仍需遵循最小權限原則 (Least Privilege)，並開啟 Cloud Audit Logs 監控所有令牌交換事件。同時，必須意識到 WIF 僅適用於機器對機器的認證，人類使用者的認證應使用 Cloud Identity 或 Workforce Identity Federation。
總結而言，從服務帳號金鑰轉向 Workload Identity Federation，代表著從「維護秘密」到「配置信任」的思維轉型。它消除了金鑰輪替的維運負擔，並在設計上根除了金鑰意外提交至版本控制系統的風險。對於任何在 GCP 上運行 CI/CD 管道或對接第三方服務的團隊，WIF 應被視為認證的首選方案。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。