如果您提供的產品或服務可讓客戶分析或管理資料/資源,客戶可能想存取 Trusted Cloud 環境中的資料或其他資源。這類產品和服務的範例如下:
- 資料分析產品:客戶可能想使用這類產品,在 BigQuery 中分析資料。
- CI/CD 產品和服務:客戶可能會使用這類服務,將基礎架構和應用程式部署到 Trusted Cloud 專案。
- 機器人程序自動化 (RPA):客戶可能會使用 RPA 執行工作流程,例如在 Trusted Cloud中建立專案、管理存取權或自動執行管理工作。
如要驗證地端或軟體即服務 (SaaS) 產品,客戶通常會使用服務帳戶金鑰,但這些金鑰難以管理及安全儲存。 Trusted Cloud
如果您是地端或軟體即服務 (SaaS) 產品的供應商,可以讓客戶使用 Workload Identity Federation 存取 Trusted Cloud 資源,協助他們保護 Trusted Cloud 資源。目前已允許客戶使用工作負載身分聯盟的服務包括 Terraform Cloud、GitHub 和 GitLab。
本文說明如何擴充產品,以支援工作負載身分聯盟,並介紹可遵循的最佳做法。本文假設您已熟悉 Workload Identity 聯盟和 OpenID Connect。
架構
Workload Identity Federation 的目的是讓客戶將產品或服務與自己的Trusted Cloud 環境聯合,藉此移除服務帳戶金鑰的需求。客戶就能使用產品或服務聲明的身分,存取Trusted Cloud 資源。
如要讓客戶使用 Workload Identity Federation,您的產品或服務必須實作 OpenID Connect 的子集。具體來說,您必須允許工作負載取得符合下列條件的 ID 權杖:
- 這個權杖會識別產品或平台中的工作負載
- 權杖會識別產品或平台的執行個體、租戶或安裝項目
- 權杖包含加密簽章,Workload Identity 聯盟可用於驗證權杖的真實性
需求條件
如要支援 Workload Identity 聯盟,請確保產品或服務符合下列規定:
工作負載可存取有效的 ID 權杖。
在生命週期內,工作負載必須隨時存取 ID 權杖,以聲明工作負載的身分,並符合 OpenID Connect 1.0 定義的需求。
由於 ID 權杖的生命週期有限,您必須確保 ID 權杖的生命週期比工作負載長,或是工作負載可以定期取得新的 ID 權杖。
ID 權杖可唯一識別工作負載。
ID 權杖至少須包含一項聲明,用來專門識別工作負載。工作負載 ID 不得變更。
對於支援多重租戶的產品或服務,權杖也必須包含至少一項可明確識別租戶的聲明。租戶 ID 也必須是不可變動的值。
ID 權杖已簽署,但未加密。
OpenID 提供者中繼資料可公開存取,且可從 ID 權杖探索。
您必須在可公開存取的端點上提供 OpenID 提供者設定文件,該端點可使用 OpenID 核發者探索通訊協定探索。舉例來說,如果 ID 權杖包含值為
https://service.example.com/v1/
的iss
聲明,您就必須在https://service.example.com/v1/.well-known/openid-configuration
上提供 OpenID 提供者設定文件,且端點必須可透過網際網路從任何 IP 位址公開存取。簽署金鑰可公開存取,並可從 OpenID 提供者中繼資料探索。
您必須在可公開存取的端點提供 JSON Web Key Set (JWKS) 文件,該端點可從 OpenID 提供者中繼資料的
jwks_uri
欄位探索。
最佳做法
將產品或服務擴充為支援 Workload Identity 聯盟時,請考慮下列最佳做法。
最佳做法:
區別身分和存取權杖。以與用戶端程式庫相容的方式公開 ID 權杖。
使用租戶專屬的發行者網址。
允許使用者指定 ID 權杖目標對象。
在 ID 權杖聲明中使用不可變更且無法重複使用的 ID。
在 ID 權杖中加入情境資訊。
將 ID 權杖的生命週期限制在 30 到 60 分鐘。
區分 ID 權杖和存取權杖
在 Workload Identity Federation 的脈絡中,ID 權杖的用途是聲明工作負載的身分:權杖必須包含足夠的資訊,讓 Workload Identity Federation 識別工作負載,並將其與其他工作負載區分開來。
與 ID 權杖不同,存取權杖通常有不同用途:用於做出存取決策,且可能包含工作負載擁有的權限,或允許存取的 API 等資訊。
如果您的產品或服務使用存取權權杖,讓工作負載呼叫產品的 API 等用途,這些存取權權杖可能不適合 Workload Identity Federation。請考慮導入第二種權杖 (符合 ID 權杖的定義),讓工作負載使用 ID 權杖進行 Workload Identity 聯盟,而非將存取權杖重新用於 ID 權杖。
以與用戶端程式庫相容的方式公開 ID 權杖
Trusted Cloud 用戶端程式庫可自動從多個來源取得 ID 權杖,包括:
- HTTP 端點 (網址來源憑證)
- 本機檔案 (檔案來源憑證)
如要從其他來源取得 ID 權杖,客戶可能需要修改程式碼,或部署其他工具或程式庫。以與用戶端程式庫相容的方式公開 ID 權杖,即可避免這類額外的複雜性,並讓客戶更輕鬆地採用工作負載身分聯盟。
使用租戶專屬的簽發者網址
工作負載 ID 權杖中嵌入的聲明在特定產品或服務執行個體中可能是唯一的,但在多個產品或服務執行個體中可能不是唯一的。舉例來說,兩位客戶可能會使用您的產品或服務部署工作負載,並無意間為這些工作負載指派相同的名稱和 ID。
為彌補這項可能缺乏獨一性的問題,Workload Identity Federation 會驗證 ID 權杖的核發者 URL (iss
),並只允許每個工作負載身分集區使用單一核發者的權杖。
如果您的產品或服務支援多重租戶,則多位客戶可能會共用單一產品或服務執行個體,且工作負載的 ID 權杖可能會使用相同的簽發者 URL。在多個租戶中使用相同的發行者網址,可能會導致客戶遭受網路釣魚攻擊。舉例來說,惡意行為人可能會在自己的租戶中建立工作負載,並指派與受害者租戶中工作負載相同的 ID 或名稱,然後使用工作負載的 ID 權杖,偽造受害者工作負載的身分。
為保護顧客免於遭受網路釣魚攻擊,請避免在多個租戶中使用相同的簽發者網址,並在簽發者網址中嵌入專屬的租戶 ID,例如 https://saas.example.com/tenant-123/
。
允許使用者指定 ID 權杖目標對象
客戶的部分工作負載可能需要存取 Trusted Cloud以及其他第三方服務。當客戶決定將產品或服務與多個信賴方聯合時,可能會遇到以下情況:工作負載的 ID 權杖遭到誤用或惡意使用,導致權杖用於錯誤的信賴方。舉例來說,惡意行為人可能會誘騙工作負載揭露原本要用於第三方服務的 ID 權杖,然後將該權杖用於 Workload Identity Federation。
為避免客戶成為這類「混淆副手」攻擊的受害者,請勿在 ID 權杖中使用靜態目標對象 (aud
聲明)。而是讓工作負載在取得 ID 權杖時指定目標對象,並視需要維護工作負載可要求的目標對象允許清單。
根據預設,Workload Identity Federation 會要求 ID 權杖的對象與網址 https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
相符。
請確認工作負載可將網址做為 ID 權杖的目標對象,且目標對象網址長度少於 180 個字元。
在 ID 權杖聲明中使用不可變更且無法重複使用的 ID
客戶如要授予其中一項工作負載資源存取權,必須建立 IAM 繫結,並依主體、群組或自訂屬性參照工作負載的身分。 Trusted Cloud工作負載 ID 權杖中的聲明會衍生出工作負載身分的主體、群組和自訂屬性。
如果客戶建立的 IAM 繫結參照了可變動的聲明,當聲明的值變更時,工作負載可能會意外失去存取權。舉例來說,客戶可能會建立參照工作負載名稱的 IAM 繫結。如果使用者隨後重新命名工作負載,IAM 繫結可能就不會再套用。
更糟的是,惡意行為者可能會刻意重新命名工作負載或修改工作負載的環境,藉此模擬其他工作負載的身分,試圖未經授權存取其他資源。
為協助顧客避免這類詐欺問題,請確保 ID 權杖包含不可變動且無法重複使用的 ID。
在 ID 權杖中加入脈絡資訊
客戶可能不想授予工作負載無條件存取 Trusted Cloud 資源的權限,而是限制存取權,讓工作負載只能在符合特定額外條件時取得 Google 憑證。
如要讓客戶設定這類限制,請在 ID 權杖中加入含有內容資訊的其他聲明。背景資訊範例如下:
- 擁有或啟動工作負載的使用者相關資訊
- 工作負載的啟動原因和方式
- 工作負載目前處理的要求
將 ID 權杖效期限制為 60 分鐘
ID 權杖的效期有限,由 exp
聲明決定。工作負載使用 ID 權杖執行權杖交換時,Workload Identity Federation 會驗證 ID 權杖的 exp
聲明,並核發 STS 權杖,有效時間與輸入權杖相同,但最長為 1 小時。
使用效期超過一小時的 ID 權杖不會影響 Workload Identity Federation,但如果 ID 權杖意外洩漏,可能會增加風險。將生命週期設為遠低於 1 小時,有助於降低這類風險,但可能會導致權杖交換頻率提高,進而降低效能。