如果外部系統根本不需要金鑰檔呢

前兩篇的討論，都是「假設你必須用金鑰檔，該怎麼把風險降到最低」。但更根本的解法是：讓外部工作負載（CI/CD pipeline、on-prem 伺服器、其他雲端平台上的服務）完全不需要下載、儲存任何 GCP 金鑰檔，就能取得存取 GCP 資源的權限。這正是 Workload Identity Federation（WIF）要解決的問題。

WIF 的運作邏輯

WIF 的核心概念是「身份聯盟」：外部身份提供者（例如 GitHub Actions 的 OIDC token、AWS IAM Role、企業內部的 Identity Provider）簽發的短效憑證，透過事先設定好的信任關係，換取一組短效的 GCP 存取權杖（access token），這組權杖再被授權去模擬（impersonate）一個 GCP Service Account，取得該 SA 所擁有的權限。

整個流程裡完全沒有 JSON 金鑰檔案的存在，換來的權杖也是短效的，用完即失效。

典型應用場景

CI/CD Pipeline（例如 GitHub Actions）：部署流程需要呼叫 GCP API 部署到 Vertex AI，過去做法是把 Service Account 金鑰存成 GitHub Secrets，現在改用 WIF，讓 GitHub Actions 的 OIDC token 直接換取短效權杖，Secrets 裡完全不需要放 GCP 金鑰。

企業內部系統整合企業 IdP：本地端系統要呼叫 Gemini API，透過企業既有的 Identity Provider（如 Okta、Azure AD）做身份聯盟，避免額外管理一套獨立的 GCP 憑證。

跨雲情境：AWS 上跑的服務要呼叫 GCP 的 Vertex AI，用 AWS IAM Role 作為外部身份，透過 WIF 換取 GCP 存取權杖，不需要在 AWS 環境裡存放 GCP 金鑰。

設定概念（示意，非可直接執行的完整指令）

# 建立 Workload Identity Pool

gcloud iam workload-identity-pools create "github-pool" \

--location="global" \

--display-name="GitHub Actions Pool"

# 建立 Provider，設定信任 GitHub 的 OIDC token

gcloud iam workload-identity-pools providers create-oidc "github-provider" \

--location="global" \

--workload-identity-pool="github-pool" \

--issuer-uri="https://token.actions.githubusercontent.com" \

--attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository"

# 將特定 repo 的身份綁定到目標 Service Account，僅能模擬該 SA

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \

--role="roles/iam.workloadIdentityUser" \

--member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/github-pool/attribute.repository/ORG/REPO"

待實測提醒：以上指令是概念性示範，實際部署前務必對照 Workload Identity Federation 官方文件 確認語法、參數名稱是否為目前版本，並在測試專案先跑過一次完整流程再推廣到生產環境。

WIF 不是萬能，這幾種情境還是需要金鑰

如果外部系統無法產生任何形式的身份 token（例如非常老舊、沒有 OIDC 支援的系統），可能還是得依賴傳統金鑰檔，這時候 Day8 提到的輪替與監控機制就是必要的備援手段，而不是可以跳過的步驟。

這篇的檢查清單

• [ ] CI/CD Pipeline 是否還在用存放的 Service Account 金鑰，而非 WIF？
• [ ] 跨雲或跨系統整合是否評估過用 WIF 取代金鑰檔？
• [ ] 對於無法支援 WIF 的舊系統，是否有替代的金鑰管控機制？