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