Workload Identity 聯盟可讓在 Google Cloud外部執行的應用程式，使用外部身分識別提供者的憑證模擬服務帳戶。
使用 Workload Identity 聯盟可讓應用程式使用外部環境提供的驗證機制，有助於提升安全性，並取代服務帳戶金鑰。
如要安全地使用 Workload Identity 聯盟，您必須設定這項功能，防範下列威脅：
- 冒用：不肖人士可能會試圖冒用其他使用者的身分，以未經授權的方式存取 Google Cloud 資源。
- 權限提升：惡意行為者可能會利用 Workload Identity Federation 存取他們原本無法存取的資源。
- 不可否認性：惡意人士可能會使用外部憑證隱藏身分和動作，導致難以追蹤其動作。
- 惡意憑證設定：惡意行為人可能會提供惡意憑證設定，藉此規避安全防禦措施。
本指南介紹最佳做法，協助您決定何時使用 Workload Identity 聯盟，以及如何設定這項功能，盡量降低風險。
使用 Workload Identity 聯盟的時機
最佳做法：
針對可存取環境認證的應用程式，使用 Workload Identity Federation。使用額外的權杖交換，以使用 Workload Identity 聯盟不支援的環境憑證。
使用 Workload Identity 聯盟，減少需要輪替的憑證數量。
針對可存取環境認證的應用程式使用 Workload Identity 聯盟
在 Google Cloud 以外的雲端服務供應商上執行的應用程式，通常可以存取環境憑證。應用程式可取得這些憑證，不必執行任何額外驗證。相關例子包括：
- 在 AWS 上，部署於 EC2 的應用程式可以使用執行個體設定檔承擔角色並取得臨時憑證。
- 在 Azure 中，應用程式可以使用受控識別取得存取權權杖。
- 在 GitHub Actions 中，工作流程可以取得 ID 權杖，反映部署作業的身分。
如果環境憑證是 OpenID Connect (OIDC) 權杖、SAML 判斷或 AWS 憑證，您可以設定 Workload Identity 聯盟，讓應用程式將這些憑證換成短期 Google 存取權杖。如果環境憑證使用其他格式，您可能需要先將憑證換成 OIDC 權杖或 SAML 聲明，然後再用於工作負載身分聯盟。
每當應用程式需要存取Google Cloud 且有權存取環境憑證時，請使用 Workload Identity 聯盟。
使用額外的權杖交換，以使用 Workload Identity 聯盟不支援的環境憑證
在某些情況下，應用程式可能可以存取環境憑證，但工作負載身分聯盟不支援這些憑證類型。在這些情況下，請檢查額外的權杖交換作業是否可讓您將環境憑證轉換為可用於工作負載身分聯盟的憑證類型。
舉例來說，如果應用程式在 Active Directory 環境中執行，可能可以存取 Kerberos 憑證。如果您的環境中有支援整合式 Windows 驗證的識別資訊提供者 (例如 Active Directory Federation Services (AD FS))，您可以使用這些 Kerberos 憑證向識別資訊提供者進行驗證，並取得採用 JWT 格式的 OAuth 存取權杖。您可以使用這個存取權杖和 Workload Identity Federation，讓應用程式執行第二次權杖交換，以取得短期 Google 憑證。
串連權杖交換會增加複雜度，並可能導入額外的依附元件，但可免除管理及保護服務帳戶金鑰的麻煩。
使用 Workload Identity 聯盟，減少需要輪替的憑證數量
與 OpenID 或 SAML 識別資訊提供者整合的應用程式，通常會使用用戶端密碼 (或其他形式的密碼) 向識別資訊提供者進行驗證。這個密鑰通常會儲存在應用程式設定中。如要允許這類應用程式存取 Google Cloud，請選擇下列其中一種做法：
- 建立服務帳戶金鑰，並與其他密鑰一併儲存。
- 使用現有身分識別提供者核發的權杖，並透過 Workload Identity Federation 將權杖換成 Google 憑證。
第一個選項需要兩個密鑰，但第二個選項只需要一個。 減少密鑰數量有助於簡化密鑰輪替作業，進而提升安全性。
防範詐欺威脅
工作負載身分集區不含任何身分或使用者帳戶，因此與 Cloud Identity 等使用者目錄不同。工作負載身分集區代表的是「檢視畫面」，可顯示來自外部身分提供者的身分，以便做為 IAM 主體使用。
視工作負載身分集區及其提供者的設定方式而定，同一個外部身分可能會以多個不同的 IAM 主體表示，或多個外部身分可能會對應至同一個 IAM 主體。這類模糊不清的資訊可能會讓不肖人士發動網路釣魚攻擊。
以下章節將說明最佳做法，有助於避免模稜兩可的對應，並降低遭到詐騙的風險。
最佳做法：
與 GitHub 或其他多租戶識別資訊提供者聯合時，請使用屬性條件。使用專屬專案管理工作負載身分集區和提供者。
使用機構政策限制，禁止在其他專案中建立 workload identity pool 提供者。
每個工作負載身分識別集區使用單一提供者，避免主體發生衝突。
避免與同一識別資訊提供者聯合兩次。
保護身分識別提供者的 OIDC 中繼資料端點。
將 workload identity pool 提供者的網址做為對象。
在屬性對應中，使用不可變動的屬性。
在屬性對應中使用不可重複使用的屬性。
不允許修改屬性對應。
請勿依賴不穩定或不具權威性的屬性。
與 GitHub 或其他多租戶身分識別提供者聯合時，請使用屬性條件
工作負載身分聯盟不會維護使用者帳戶目錄，而是實作以聲明為準的身分：因此，如果兩個權杖是由同一個身分提供者 (IdP) 發行，且聲明對應至相同的 google.subject 值，系統就會假設這兩個權杖識別的是同一位使用者。如要瞭解是哪個 IdP 核發權杖，Workload Identity 聯盟會檢查並驗證權杖的核發者 URL。
部分供應商 (例如 GitHub 和 Terraform Cloud) 會在所有租戶中使用單一簽發者網址。對於這些供應商，簽發者網址會識別「所有 GitHub 或 Terraform Cloud」，而非特定 GitHub 或 Terraform Cloud 機構。
使用這些身分識別提供者時，Workload Identity Federation 檢查權杖的簽發者網址，確保權杖來自可信任的來源，且其聲明可信任，這還不夠。建議您設定工作負載身分聯盟屬性條件，檢查權杖是否來自信任的租戶，或是 GitHub 或 Terraform Cloud 的信任機構。
詳情請參閱「設定屬性條件」。
使用專案管理 workload identity pool 和提供者
您可以使用單一專屬專案管理 Workload Identity 集區和提供者，不必在多個專案中管理。使用專屬專案有助於：
- 請務必只使用受信任的識別資訊提供者，進行工作負載身分聯盟。
- 集中控管 Workload Identity 集區和提供者的設定存取權。
- 在所有專案和應用程式中，套用一致的屬性對應和條件。
您可以使用機構政策限制，強制規定使用專屬專案管理工作負載身分集區和提供者。
使用機構政策限制，禁止在其他專案中建立 workload identity pool 提供者
有權建立 workload identity pool 提供者的使用者，可以建立 workload identity pool 和提供者，但這些項目可能與您在專屬專案中管理的項目重複。
如要禁止建立新的工作負載身分集區提供者，請使用constraints/iam.workloadIdentityPoolProviders機構政策限制，並將規則設為「全部拒絕」。
在機構階層的根層級套用這些限制，預設禁止建立新的 workload identity pool 提供者。為要允許管理 Workload Identity 集區和提供者的專案建立例外狀況，方法是套用政策限制，允許特定受信任的 AWS 帳戶或 OIDC 提供者。
每個工作負載身分集區使用單一提供者，避免主體衝突
使用工作負載身分聯盟，每個工作負載身分集區可建立多個提供者。如果身分是由多個供應商管理，但您想對在 Google Cloud上執行的工作負載隱藏這項複雜性，使用多個供應商就相當實用。
使用多個供應商會導致主體衝突的風險，也就是一個供應商的 google.subject 屬性對應會傳回與另一個供應商屬性對應相同的值。發生這類衝突時，多個外部身分會對應至相同 IAM 主體，導致 Cloud Audit Logs 無法區分外部身分。
為避免主體衝突，每個工作負載身分集區只能使用一個提供者。 如要與多個供應商進行同盟，請建立多個工作負載身分識別集區，每個集區使用單一工作負載身分識別供應商。
避免與同一個識別資訊提供者建立兩次聯盟
您可以建立多個使用相同或類似設定的工作負載身分識別集區供應商，多次與同一身分識別提供者進行同盟。如果這些提供者屬於同一個 workload identity pool，這類設定可能會導致主體衝突。如果供應商屬於不同的工作負載身分集區，就不會發生主體衝突，而是以不同的 IAM 主體代表相同的外部身分。
如果將單一外部身分對應至多個 IAM 主體，分析特定外部身分可存取哪些資源時，就會更加困難。嘗試撤銷存取權時，這種模糊不清的情況也可能增加風險：管理員可能會撤銷某個主體的存取權，但可能不知道有另一個主體，導致外部身分無意間保留存取權。
為盡量降低模糊不清的風險，請避免與同一身分提供者聯合驗證多次。請改為建立單一工作負載身分集區和供應商，並使用屬性對應和條件，確保該集區和供應商可用於所有需要存取 Google Cloud 資源的外部身分。
保護身分識別提供者的 OIDC 中繼資料端點
與 OpenID Connect 提供者聯合時，Workload Identity Federation 會定期從識別資訊提供者下載 OIDC 中繼資料。Workload Identity 聯盟會使用 IdP 的中繼資料和 JSON Web Key Set (JWKS) 驗證權杖。
為確保真實性，與身分識別提供者的通訊會使用 TLS 加密。如果您的供應商部署在終止 TLS 的負載平衡器或反向 Proxy 後方，則 TLS 連線可確保負載平衡器或反向 Proxy 的真實性，但無法確保實際身分識別提供者的真實性。
惡意行為人可能會利用這項設定發動攔截式攻擊，重新設定負載平衡器，將 JWKS 要求傳送至惡意端點，該端點會提供另一組金鑰。如果惡意行為人替換 JWKS，就能簽署 Workload Identity 聯盟視為有效的權杖，並可能藉此偽造其他使用者的身分。
為防範 JWKS 交換，請確保 IdP 的部署方式能防範中間人攻擊。
將 workload identity pool 提供者的網址做為目標對象
與 OpenID Connect 提供者建立聯盟時，Workload Identity Federation 會驗證權杖的對象 (編碼於 aud 宣告中) 是否與提供者的允許對象設定相符。同樣地，當您與 SAML 提供者建立聯盟時，Workload Identity Federation 會檢查 SAML 聲明是否指定符合預期目標對象的目標對象限制。
根據預設，Workload Identity 聯盟會要求對象與網址相符，
https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
該網址會唯一識別工作負載身分集區提供者。規定必須提供權杖和聲明，才能將這個網址做為目標對象，有助於降低混淆副手攻擊的風險。在這種攻擊中，惡意行為人會向 Workload Identity Federation 提交權杖或 SAML 聲明，但這些權杖或聲明並非用於 Workload Identity Federation，而是用於其他 API。
要求權杖或聲明包含目標工作負載身分集區供應商的網址，有助於確保用戶端只能使用專為工作負載身分聯盟核發的權杖和聲明。
在屬性對應中使用不可變更的屬性
如要授予外部身分模擬服務帳戶的權限，請建立 IAM 繫結，並依主體、群組或自訂屬性參照外部身分。外部身分的主體、群組和自訂屬性，是從外部身分提供者在權杖交換期間傳遞至 Workload Identity Federation 的屬性衍生而來。
部分身分識別提供者允許使用者變更自己的某些屬性。 舉例來說，使用者可能可以修改電子郵件地址或別名。 如果 IAM 繫結參照可修改的屬性，使用者可能會因為修改使用者設定檔，而意外失去特定資源的存取權。更糟的是，惡意行為者可能會刻意修改使用者屬性，使其符合現有的 IAM 繫結，藉此未經授權存取其他資源。
為防範這類詐欺威脅，請將屬性對應限制為使用者無法修改或完全無法修改的屬性。
在屬性對應中使用不可重複使用的屬性
如果您授予外部身分模擬服務帳戶的權限，隨後刪除外部身分提供者中的使用者，服務帳戶的 IAM 繫結仍會保留。
如果您稍後在外部身分識別提供者中新增使用者，且該使用者與先前刪除的使用者共用特定屬性 (例如相同的電子郵件地址)，則 Workload Identity Federation 無法區分新舊使用者。因此，原本只應參照舊使用者的 IAM 繫結，可能也會套用至新使用者。
為避免這類模稜兩可的情況，請使用屬性對應，只依據不會重複使用的屬性 (例如專屬使用者 ID)。
如果公司政策允許重複使用電子郵件地址等屬性，請避免在屬性對應中使用這些屬性，改用可確保長期保持不重複的屬性。
禁止修改屬性對應
工作負載身分聯盟會使用屬性對應，選取要將外部身分提供者提供的哪些屬性嵌入 STS 權杖，以及屬性名稱的翻譯方式。設定屬性對應是設定外部身分識別提供者與 Google Cloud之間信任關係的重要步驟。
屬性對應對於使用工作負載身分聯盟的安全性也至關重要：如果您已授予聯盟主體或主體集模擬服務帳戶的權限，然後變更屬性對應，可能會變更哪些使用者有權存取服務帳戶。
如要修改屬性對應，必須具備 iam.googleapis.com/workloadIdentityPoolProviders.update 權限。包含這項權限的角色包括：
- 擁有者 (
roles/owner) - 身分與存取權管理 Workload Identity 集區管理員 (
roles/iam.workloadIdentityPoolAdmin)
如果惡意行為人有權修改屬性對應，他們或許就能變更對應規則，藉此偽造身分並存取服務帳戶。為防止這類惡意修改，請確保只有少數管理員使用者有權修改屬性對應。
建議您建立專屬 Google Cloud 專案來管理工作負載身分集區，這樣有助於降低使用者在資源階層中較高層級，不慎獲授這些角色的風險。
請勿依賴不穩定或不具權威性的屬性
身分識別提供者會使用屬性傳達經過驗證的使用者資訊。身分識別提供者通常會保證某些屬性具有授權性，但其他屬性則不一定。舉例來說，外部身分識別提供者可能會在 OIDC 權杖中嵌入使用者名稱和使用者 ID。這兩個屬性都能識別不重複使用者，因此似乎可以互換。 不過，外部身分識別資訊提供者可能會保證使用者 ID 穩定且具權威性，但允許變更使用者名稱。
如果屬性對應項目依賴不穩定或不具權威性的屬性，惡意行為人可能會修改外部身分識別資訊提供者中的使用者設定檔，藉此偽造身分。舉例來說，使用者可能會將使用者名稱變更為外部身分識別提供者中最近刪除的使用者名稱，但仍可存取 Google Cloud上的服務帳戶。
為防範這類假冒攻擊，請確保屬性對應只依據外部身分識別提供者保證穩定且具權威性的屬性。
防範不可否認性威脅
每當您發現Google Cloud上的某項資源受到可疑活動影響時，Cloud 稽核記錄就是重要的資訊來源，可協助您找出活動發生時間和涉及的使用者。
應用程式使用 Workload Identity 聯盟時，會模擬服務帳戶。在 Cloud 稽核記錄中，應用程式執行的任何活動都會歸因於模擬的服務帳戶。如要重構導致活動的完整事件鏈，您必須能夠將 Cloud 稽核記錄與身分識別提供者的記錄建立關聯，找出涉及的外部身分，以及執行活動的原因。
本節說明最佳做法，協助您維護不可否認的稽核追蹤記錄。
啟用 IAM API 的資料存取記錄
為協助您識別及瞭解服務帳戶模擬情境，Compute Engine 等服務會在 Cloud Audit Logs 中加入 serviceAccountDelegationInfo 區段。應用程式使用 Workload Identity 聯盟時，這個部分會包含主體的主旨，該主體用於模擬服務帳戶。
並非所有服務都會在 Cloud 稽核記錄中加入模擬詳細資料。為協助維護不可否認的稽核追蹤記錄，您也必須啟用資料存取記錄，記錄所有模擬事件，包括 Security Token Service API 和 Identity and Access Management API。請為所有包含工作負載身分集區或用於 Workload Identity Federation 的服務帳戶，啟用這些記錄。
啟用這些記錄後，每當應用程式使用 Workload Identity Federation交換外部憑證和模擬服務帳戶時，系統就會在 Cloud Audit Logs 中新增項目。
使用不重複的主旨對應
Cloud Audit Logs 項目中serviceAccountDelegationInfo 部分使用的主要主體，取決於工作負載身分集區供應商的 google.subject 屬性對應。
發現可疑活動並需要找出涉及的外部身分時，您必須能夠透過對應的 google.subject 值查詢外部身分。
同樣地，如果外部身分遭到入侵，您需要瞭解該身分是否曾用於存取 Google Cloud 資源，就必須能夠找出與該外部身分相應的 Cloud 稽核記錄檔項目。
為工作負載身分集區提供者定義屬性對應 時，請為 google.subject 選擇不重複的對應，確保：
- 外部身分只能對應至一個
google.subject值。 - 一個
google.subject值只能對應一個外部身分。 - 您可以透過外部身分的
google.subject值查詢外部身分。
使用符合這些唯一性條件的屬性對應關係，有助於確保您可以依 google.subject 值查詢外部身分，以及依外部身分查詢 google.subject 值。
防範權限提升威脅
使用 Workload Identity 聯盟時，如要套用最低權限原則，請務必：
- 限制可模擬服務帳戶的外部身分數量
- 限制服務帳戶可存取的資源
如果設定過於寬鬆，惡意行為人可能會使用外部身分提升權限，並存取不應存取的資源。
下列各節提供最佳做法，有助於防範權限提升威脅。
使用與您要存取的資源位於同一專案的服務帳戶
當用戶端使用用戶端程式庫或REST API 使用 Workload Identity Federation 時，會依循下列三步驟程序：
- 向可信任的識別資訊提供者取得憑證。
- 向 Security Token Service 換取憑證的權杖。
- 使用安全權杖服務中的權杖模擬服務帳戶，並取得短期 Google 存取權杖。
最後一個步驟是使用與您要存取的資源位於同一專案的服務帳戶。使用在同一專案中管理的服務帳戶，有助於套用更嚴格的存取權限，並更容易判斷何時可能不再需要服務帳戶。
為每個應用程式使用專屬服務帳戶
如果您有多個應用程式使用 Workload Identity Federation 存取同一專案中的資源，請為每個應用程式建立專屬服務帳戶。使用應用程式專屬的服務帳戶，只授予各個應用程式所需的資源存取權，有助於避免過度授權。
避免授予集區的所有成員存取權
外部身分模擬服務帳戶前，您必須授予該身分服務帳戶的 roles/iam.workloadIdentityUser 角色。授予這個角色時，請避免將角色授予工作負載身分集區的所有成員。請改為將角色授予特定外部身分，或符合特定條件的身分。
一開始，需要存取 Google Cloud資源的外部使用者人數可能不多。因此，工作負載身分集區的屬性條件和身分識別提供者的設定，可能只允許少數外部身分使用 Workload Identity 聯盟。
日後將新工作負載加入 Google Cloud時，您可能需要修改身分識別提供者的設定或工作負載身分集區的屬性條件，以允許其他外部身分。
只將 roles/iam.workloadIdentityUser 角色授予特定外部身分，即可確保安全擴充工作負載身分集區，不會不慎授予過多外部身分模擬存取權。
防範惡意憑證設定
部分憑證設定含有網址和檔案路徑，如果工作負載未適當驗證，可能會導致工作負載使用惡意端點。
先從外部來源驗證憑證設定，再用來向 Google API 驗證身分
接受外部來源的憑證設定時，您必須先驗證 JSON，才能使用。如果您未驗證憑證設定，惡意行為人可能會利用憑證設定，導致工作負載存取惡意端點。
詳情請參閱「使用外部來源的憑證設定時的安全規定」。
後續步驟
- 瞭解使用服務帳戶的最佳做法。
- 進一步瞭解管理服務帳戶金鑰的最佳做法。