關於 GKE 的代理程式身分

與其他類型的工作負載相比，代理工作負載通常需要不同的防禦措施、存取控管和驗證工作流程。您可以使用代理身分，為每個代理提供經過認證、時效短暫的 Pod 身分。這個身分可協助您識別代理程式工作負載，並追蹤及管理這些工作負載在 Google Cloud中的活動。本文說明 Google Kubernetes Engine (GKE) 中的代理程式身分運作方式，包括如何與其他Google Cloud 產品整合、代理程式可使用的驗證類型，以及如何使用這些身分控管工作負載。

本文適用於平台管理員和安全工程師，他們希望在將代理程式與 Google Cloud 產品和服務整合時，提升在 GKE 叢集上執行的代理程式安全性。

您應該已熟悉下列主題：

什麼是代理人身分？

Google Cloud 為工作負載提供各種身分類型，每種身分類型都適用於特定用途和工作負載類型。代理身分是專為 AI 代理工作負載設計的身分類型。使用代理身分的代理會取得根據 SPIFFE 標準的專屬身分。這個身分與代理的生命週期繫結，可將工作負載識別為代理，並由各種 Gemini Enterprise Agent Platform 服務 (例如 Agent Registry 和 Agent Gateway) 辨識。您可以追蹤及管理具有代理程式身分的工作負載，無論該工作負載在何處執行，都能跨工作負載存取的所有服務進行管理。使用代理身分的工作負載可透過自身身分或代表使用者，向 MCP 伺服器、 Google Cloud內外資源、其他代理和端點進行驗證。如要進一步瞭解 Agent Identity，請參閱「Agent Identity 總覽」。

您可以運用代理程式身分，提升在 GKE 叢集中部署的 AI 代理程式安全性與控管能力，並為代理程式啟用特定工作流程，例如：

  • 將 GKE 上的代理與 Agent Registry 和 Agent Gateway 等產品整合。
  • 在 Identity and Access Management (IAM) 政策中，管理專案、資料夾或機構的代理程式工作負載角色。
  • 減少受駭代理程式對叢集中節點和其他 Pod 的影響。
  • 使用 Agent Identity 驗證管理工具設定各種驗證工作流程，例如代理人代表終端使用者執行動作。

與 Workload Identity Federation for GKE 比較

Agent Identity 和 Workload Identity Federation for GKE 都能為工作負載提供身分。代理程式身分是針對威脅模型和適用於 AI 代理程式的特定需求所設計，因此在功能上有所差異。下表概略比較了這些差異：

Agent Identity Workload Identity Federation for GKE
代理程式身分存取權杖可以加密方式繫結至每個 Pod 的 X.509 憑證。繫結存取權杖需要 mTLS 連線，且無法在原始 Pod 以外使用。 聯合存取權杖不會以密碼編譯方式繫結至 Pod 身分，可透過非 mTLS 連線運作，且可在原始 Pod 外部使用。
與 Agent Identity 驗證管理工具整合，支援 OAuth 工作流程，並使用第三方憑證，不必手動管理憑證。 驗證外部工具和服務時，需要手動實作 OAuth 工作流程，並管理第三方憑證。
適合用於自主工作負載，例如 AI 代理。 適合用於網路伺服器、API 和批次工作等確定性微服務。
需要 GKE 1.37.0-gke.3503000 以上版本。 適用於所有 GKE 版本。
繫結的代理程式身分存取權杖一律使用https://www.googleapis.com/auth/cloud-platform存取權範圍。不支援自訂範圍。 同盟存取權杖支援自訂存取權範圍。
應用程式可以取得代理程式身分 ID 權杖，直接向其他工作負載或下游服務進行驗證。 除非 Kubernetes ServiceAccount 設定為模擬 IAM 服務帳戶，否則應用程式無法取得 ID 權杖。

與 Agent Platform 整合

Gemini Enterprise Agent Platform 包含多項產品和服務，專為大規模建構、管理及運作代理而設計。如果您在 GKE 上執行代理工作負載，則可將代理身分指派給工作負載，並在 Agent Registry 中將工作負載註冊為代理，藉此使用 Agent Platform 產品。如要整合及使用 Agent Platform 服務和 GKE 代理程式，應用程式運算子會將註解和標籤新增至代理程式工作負載的 Kubernetes 規格。除了確認已啟用 Workload Identity Federation for GKE 之外，您不需要變更叢集或節點集區設定。然後，您就能以管理 Agent Runtime 或 Cloud Run 代理的方式，管理及控管 GKE 代理。

在 Agent Registry 中註冊專案，也有助於在您將專案從一個機構移至另一個機構時，避免發生潛在的服務中斷問題。在專案遷移期間，Agent Registry 會檢查是否有任何代理使用以機構層級信任網域為依據的代理身分，這類身分會在遷移後變更。如果使用機構層級的代理程式身分，系統會封鎖專案遷移作業。這項檢查只會針對您在 Agent Registry 中註冊的部署作業進行。其他工作負載控制器或靜態 Pod 不會進行檢查。

在 GKE 中的運作方式

在 GKE 中，Agent Identity 會使用 GKE 中繼資料伺服器和身分集區等概念，與 Workload Identity Federation for GKE 類似。如要使用 Agent Identity，您也必須在叢集中為 GKE 啟用 Workload Identity Federation for GKE。 Google Cloud 會在專案或機構層級自動建立Agent Identity 集區。代理程式身分集區是 SPIFFE 信任網域，也是代理程式身分和憑證的信任根。應用程式開發人員可以在 Pod 規格中加入註解和標籤，為代理程式要求代理程式身分。將工作負載部署至叢集時，GKE 會為工作負載指派下列憑證：

  • 可識別工作負載的 SPIFFE 身分。受管理工作負載 (例如 Deployment) 中的所有 Pod 都會共用該工作負載的 SPIFFE ID。SPIFFE ID 可在各項 Google Cloud 服務中識別代理程式。無論是代理還是代表一般使用者，您都可以使用 SPIFFE ID 追蹤 Pod 執行的任何動作。SPIFFE ID 的語法如下：

    spiffe://TRUST_DOMAIN/resources/container/projects/PROJECT_NUMBER/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/ns/NAMESPACE/sa/SERVICEACCOUNT_NAME

    這個 ID 字串具有下列屬性：

    • TRUST_DOMAIN：SPIFFE 信任網域，視包含叢集的專案是否位於機構中，具有下列其中一個值：
      • 機構中的專案： agents.global.org-ORGANIZATION_ID.system.id.goog， 其中 ORGANIZATION_ID 是機構的 ID。
      • 不屬於機構的專案： agents.global.proj-PROJECT_NUMBER.system.id.goog，其中 PROJECT_NUMBER 是叢集專案的專案編號。
    • PROJECT_NUMBER：叢集專案的專案編號。
    • CONTROL_PLANE_LOCATION：叢集控制層所在的區域或可用區。
    • CLUSTER_NAME：Pod 所在的叢集名稱。
    • NAMESPACE：Pod 所在的 Kubernetes 命名空間名稱。
    • SERVICEACCOUNT_NAME：指派給 Pod 的 Kubernetes ServiceAccount 名稱。

  • 代理程式身分憑證組合 (x509.credential-bundle.private-key.pem)，會以磁碟區的形式掛接在每個 Pod 中，可用於 API 的 mTLS 驗證。 Google Cloud 這個檔案包含下列憑證：

    • X.509 憑證鏈結，其中包含代理程式工作負載的 SPIFFE ID 做為「主體別名」(SAN) 參數，並在 24 小時內到期。憑證鏈結用於取得繫結存取權杖和 ID 權杖，以便向其他服務進行驗證。
    • kubelet 程序會自動為每個 Pod 建立私密金鑰。金鑰會以加密方式將 Pod 的 X.509 憑證繫結至 Pod。這個金鑰可證明提出要求的 Pod 擁有用於建立 TLS 連線的 X.509 憑證。

  • 根 CA 信任組合 (TRUST_DOMAIN.spiffe-trust-bundle.pem)，會以磁碟區的形式掛接在每個 Pod 中，可用於設定使用相同信任網域的代理程式之間的 mTLS 驗證。在 mTLS 交握期間，代理程式會使用根 CA 信任組合，驗證對等代理程式提供的憑證鏈結。

工作負載層級設定

如要將代理程式身分和每個 Pod 的憑證指派給工作負載，GKE 會在 Pod 規格中尋找下列註解：

  • iam.gke.io/identity: "spiffe://TRUST_DOMAIN/*"： GKE 會使用這個註解，從對應的信任網域為 Pod 指派 SPIFFE ID。

  • iam.gke.io/inject-podcertificates: "true"：GKE 會使用這個註解，將代理程式身分憑證組合和叢集信任組合新增至工作負載中的每個 Pod。如果省略這個註解，您就無法取得繫結至特定 Pod 的存取權杖。從 Pod 到任何Google Cloud API 或對等代理程式，都會使用注入的憑證進行 mTLS 驗證。

此外，Agent Registry 會使用下列標籤和註解自動註冊 GKE 代理：

  • registry.gke.io/functional-type: "AGENT" 標籤：將工作負載識別為 AI 代理，並將代理新增至 Agent Registry。這個標籤僅適用於部署作業，且必須在部署資訊清單的 metadata.labels 欄位中指定。
  • iam.gke.io/spiffe-identity-type: "agent-identity" 註解：表示代理使用 Agent Identity。這項註解是在 Pod 規格中指定。如果為 Deployment 指定 registry.gke.io/functional-type: "AGENT" 標籤，Pod 規格中就必須有這個註解。

如要將 GKE 代理程式與 Agent Platform 整合，除了使用代理程式身分，也請向 Agent Registry 註冊工作負載。請考慮強制註冊代理程式工作負載，或在部署管道中自動註冊。

代理的存取權杖

在 GKE 中，每個使用代理程式身分的 Pod 都會取得專屬憑證組合，內含 X.509 憑證和 Pod 的私密金鑰，不會離開 Pod。如要存取任何 Google Cloud API 或外部服務，GKE 叢集中的代理程式 Pod 會向每個節點上執行的 GKE 中繼資料伺服器，要求代理程式身分存取權杖。Pod 會使用代理程式身分存取權杖，以代理程式身分進行驗證。

存取權杖可繫結或不繫結，如下所示：

  • 繫結存取權杖：以密碼編譯方式繫結至 Pod 的 X.509 憑證，且只能透過使用該 X.509 憑證驗證的 mTLS 連線使用。如果存取權杖要求在酬載中包含 X.509 憑證，就會產生繫結權杖。
  • 未繫結的存取權杖：未以密碼編譯方式繫結至特定 Pod，且可透過非 mTLS 連線使用。未繫結的存取權杖更容易遭受權杖重播攻擊，因為遭洩漏的權杖可供其他 Pod 使用。

服務專員會使用繫結或未繫結的存取權杖，向Google Cloud API 驗證要求。身分管理員可以在 IAM 政策中指定該代理身分存取權杖的主體 ID，藉此控管代理的存取權，詳情請參閱「控管代理的資源存取權 Google Cloud 」。

如果 Pod 具有 iam.gke.io/inject-podcertificates: "true" 註解，Cloud 用戶端程式庫和 Google 驗證程式庫就會使用應用程式預設憑證 (ADC)，自動取得 Pod 的繫結代理程式身分存取權杖。這項自動程序可能不會在每個程式庫或程式設計語言中執行。如要改為要求未繫結的存取權杖，開發人員可使用下列任一方法：

  • 指定 iam.gke.io/inject-podcertificates: "true" 註解，並在 Pod 規格中將 GOOGLE_API_ENABLE_RUNTIME_BOUND_TOKEN 環境變數設為 false 值。GKE 會將 X.509 憑證組合新增至 Pod，但環境變數會導致 ADC 取得未繫結的存取權權杖。

    這個方法可讓 Pod 繼續使用憑證與其他工作負載建立 mTLS 連線，同時使用未繫結的存取權杖存取 Google Cloud API。

  • 請勿在 Pod 規格中指定 iam.gke.io/inject-podcertificates: "true" 註解。GKE 不會將 X.509 憑證組合新增至 Pod，因此 ADC 會取得 Pod 的未繫結存取權權杖。

  • 直接將 HTTP GET 要求傳送至 GKE 中繼資料伺服器的權杖端點，系統會傳回未繫結的存取權杖。

代理商的驗證工作流程

與非代理程式工作負載不同，代理程式可能需要代表使用者或以代理程式本身的身分驗證服務，具體視代理程式嘗試執行的工作而定。Agent Identity 支援使用各種憑證和驗證模型，向下列類型的資源進行驗證：

  • Google Cloud API
  • 外部工具和服務
  • 代理對代理驗證

API Google Cloud 驗證

代理程式可以使用自己的身分向 Google Cloud API 進行驗證， 例如 BigQuery 或 Agent Platform。 如要進行驗證，Pod 會從節點上的 GKE 中繼資料伺服器取得代理程式身分存取權杖。這個存取權杖可以選擇性地繫結至 Pod 的 X.509 憑證，也就是說，存取權杖只能透過使用 X.509 憑證驗證的 mTLS 連線使用。

如果應用程式使用 google-auth Python 驗證程式庫 2.61.0 以上版本，應用程式預設憑證 (ADC) 會自動為具有代理程式身分憑證套件的 Pod 要求繫結的存取權杖。如果您使用 Python 適用的 Cloud 用戶端程式庫，請務必使用包含 google-auth 程式庫 2.61.0 以上版本的版本。如要使用其他程式設計語言，或是 2.61.0 之前的 google-auth Python 程式庫版本，請改為要求未繫結的存取權杖。

如果取得繫結存取權杖，就必須使用 Pod 的 X.509 憑證，與目的地 API 的 mTLS 端點建立 mTLS 連線。如果取得未繫結的存取權杖，您就能在向該 API 的非 mTLS 端點發出的要求中使用該權杖。

如要設定應用程式程式碼，透過這些方法取得繫結或未繫結的存取權杖，請參閱「在 GKE 中使用代理程式身分驗證」。

如果您是平台管理員或安全管理員，則不需要為向Google Cloud API 驗證的身分驗證代理程式設定額外驗證。您可以按照「控管代理程式的資源存取權 Google Cloud 」一文所述，使用 IAM 政策控管資源存取權。

代理對外部服務的驗證

代理通常需要使用特定憑證 (例如 API 金鑰或 OAuth 權杖)，才能存取外部工具和服務。代理程式可能需要以自身身分或代表使用者進行驗證。您可以使用 Agent Identity 驗證管理員 (預先發布版)，為代理程式提供特定憑證。驗證管理工具會集中管理憑證取得作業，以及您在 Google Cloud執行的代理程式驗證工作流程設定。

在驗證管理員中，您可以設定驗證供應商，處理特定驗證工作流程。當 GKE 中的代理程式需要使用特定憑證進行驗證時，Pod 會使用代理程式身分存取權杖向驗證管理員進行驗證。驗證供應商接著會處理任何額外的驗證步驟，並將要求的憑證傳回 Pod。驗證管理員會將外部憑證換成短期存取權杖，因此長期更新權杖和 API 密鑰不會儲存在代理容器中。

您可以在下列用途中使用驗證管理工具，每種用途都需要在驗證管理工具和應用程式程式碼中進行特定設定和配置：

  • 代表使用者存取外部服務。
  • 以自己的身分存取外部服務。
  • 使用 API 金鑰存取 API。

您可以監控及撤銷授權管理員建立的憑證。您也可以追蹤特定服務專員使用的憑證，因為服務專員會使用服務專員身分存取權杖，向驗證管理員驗證身分。以下各節說明驗證管理員的用途，以及對應的驗證模型。視您使用的驗證模型而定，您和應用程式開發人員需要對代理程式碼和用戶端應用程式進行特定變更。

代表使用者存取外部服務

使用者可能會要求代理程式代為執行特定動作，例如在 Slack 頻道中撰寫訊息，或在 GitHub 存放區中開啟提取要求。在這些情況下，使用者會明確同意代理人代表自己行事，藉此將權限委派給代理人。如要設定使用者同意聲明和擷取憑證，請使用三足式 OAuth，並完成下列步驟：

  1. 驗證提供者會將使用者重新導向至外部服務進行驗證。
  2. 使用者登入並核准代理程式所需的存取權。
  3. 外部服務會將憑證傳回給驗證提供者。

如要為在 GKE 上執行的代理程式設定 3-legged OAuth，平台管理員和應用程式開發人員請按照下列步驟操作：

  1. 平台管理員設定驗證提供者：
    1. 在驗證管理工具中建立三足式 OAuth 驗證提供者。
    2. 設定驗證提供者，將使用者重新導向至第三方授權伺服器。
    3. 設定第三方服務，將使用者存取權杖傳送至驗證供應商。
    4. 授權代理存取驗證提供者。
  2. 應用程式開發人員修改應用程式：
    1. 修改代理程式碼，透過驗證供應商進行驗證。
    2. 修改用戶端應用程式程式碼，處理使用者登入、重新導向和繼續對話。

如要進一步瞭解如何設定驗證供應商，以及修改代理程式和用戶端應用程式，請參閱「使用驗證管理工具透過三足式 OAuth 進行驗證」。

以代理身分存取外部服務

代理人可能需要使用自己的身分存取外部服務，例如 ServiceNow 或 Salesforce。舉例來說，商品目錄管理代理可能會監控銷售資料並訂購庫存，以避免在銷售旺季特價活動期間發生缺貨問題。在這些情況下，您會使用雙足式 OAuth，其中包含下列步驟：

  1. 驗證管理員向外部服務要求存取權杖。
  2. 外部服務會驗證要求，並將存取權杖傳回給驗證管理員。

如要為在 GKE 上執行的代理程式設定 2-legged OAuth，請執行下列操作：

  1. 平台管理員設定驗證提供者：
    1. 從外部服務取得 OAuth 用戶端 ID、用戶端密鑰和權杖端點。
    2. 在驗證管理員中建立雙足式 OAuth 驗證提供者，其中包含外部服務的 OAuth 資訊。
    3. 授權代理存取驗證提供者。
  2. 應用程式開發人員會修改代理程式碼，透過驗證服務進行驗證。

如要進一步瞭解如何設定驗證供應商及修改代理程式碼，請參閱「使用驗證管理員透過雙足式 OAuth 進行驗證」。

使用 API 金鑰存取 API

您可以將 API 金鑰儲存在驗證管理工具中，供代理程式用來驗證外部 API。雖然您可以在 Secret Manager 等其他保存庫中儲存 API 金鑰，但透過驗證管理員方法，您可以在中央位置追蹤及管理代理程式對 API 金鑰的存取權。如要在 auth 管理工具中儲存及使用 API 金鑰，請執行下列操作：

  1. 平台管理員設定驗證提供者：
    1. 在驗證管理工具中建立 API 金鑰驗證提供者。
    2. 在驗證供應商中產生並儲存 API 金鑰。
    3. 授權代理存取驗證提供者。
  2. 修改代理程式碼，透過驗證供應商進行驗證。

詳情請參閱「使用驗證管理工具，透過 API 金鑰進行驗證」。

代理對代理驗證

本節說明進階驗證工作流程。您應該已熟悉下列主題：

  • JSON Web Token (JWT)：代理程式身分 ID 權杖是已簽署的 JWT。
  • JSON 物件簽署和加密 (JOSE) 標頭：ID 權杖具有 JOSE 標頭，可說明 ID 權杖的演算法和簽署金鑰。
  • JSON Web Key (JWK)：JWK 用於簽署 ID 權杖。代理程式身分集區的公開 JWK 會以 JSON Web Key Set (JWKS) 形式發布。您可以使用這些公開金鑰，驗證其他服務專員傳入的 ID 權杖。

在多代理架構中，代理通常會直接叫用同層級代理或下游服務，藉此進行協作。您可以使用代理程式身分身分權杖 (可從 GKE 中繼資料伺服器取得的已簽署 JWT)，直接在代理程式工作負載之間建立通訊。如要驗證代理程式服務之間的連線，應用程式開發人員請執行下列操作：

  1. 從 GKE 中繼資料伺服器取得呼叫代理程式的代理程式身分 ID 權杖。這個 ID 權杖必須將 aud 聲明設為接收代理的端點。
  2. 在 HTTP 要求的 Authorization: Bearer 要求標頭中加入 ID 權杖。
  3. 在接收代理程式中，使用代理程式身分集區的公開 JWK，以及 ID 權杖中的各種標頭和主體參數，驗證傳入的 ID 權杖。

如要進一步瞭解如何在應用程式程式碼中要求、使用及驗證 ID 權杖，請參閱「向其他代理程式進行驗證」。

代理程式對代理程式驗證不需要平台管理員進行額外 Google Cloud 設定，因為這項工作流程會略過 IAM 授權檢查。而是直接相互通訊，並根據代理身分授權動作。

控管代理程式的 Google Cloud 資源存取權

安全管理員可以透過參照代理主體 ID 的 IAM 政策，控管代理可存取的資源。如要控管在 GKE 上執行的代理程式資源存取權，並擁有代理程式身分，請在 IAM 政策中加入下列其中一個主體 ID：

  • 特定信任網域中的所有代理：

    principalSet://TRUST_DOMAIN/*

    在這個 ID 中，TRUST_DOMAIN 是資源階層的信任網域，取決於代理程式是否位於組織中的專案：

    • 機構中的專案： agents.global.org-ORGANIZATION_ID.system.id.goog， 其中 ORGANIZATION_ID 是機構的 ID。
    • 不屬於機構的專案： agents.global.proj-PROJECT_NUMBER.system.id.goog，其中 PROJECT_NUMBER 是叢集專案的專案編號。

  • 信任網域中的單一代理程式：

    principal://TRUST_DOMAIN/resources/container/projects/PROJECT_NUMBER/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME

    在這個 ID 中，下列參數會識別特定代理程式：

    • PROJECT_NUMBER：叢集專案的專案編號。
    • CONTROL_PLANE_LOCATION：叢集控制層的區域或可用區。
    • CLUSTER_NAME：代理程式所在的叢集名稱。
    • NAMESPACE_NAME：代理程式所在的 Kubernetes 命名空間名稱。
    • SERVICEACCOUNT_NAME：代理程式工作負載使用的 Kubernetes ServiceAccount 名稱。

如要進一步瞭解如何尋找 GKE 代理程式的主體 ID 和管理存取權，請參閱 「管理 Google Cloud 代理程式的 API 存取權」。

代理程式身分支援所有 IAM 政策類型，例如允許政策、拒絕政策和主體存取邊界 (PAB) 政策。如要管理使用代理程式身分的 GKE 叢集代理程式存取權，請在對應的政策類型中加入代理程式的主體 ID。如要進一步瞭解如何設定各類 IAM 政策，請參閱下列主題：

查看及管理各個 Google Cloud的代理程式

如果應用程式開發人員在 Agent Registry 中註冊代理，您就可以在 Google Cloud中查看 GKE 代理，以及您執行的其他代理。代理程式登錄會顯示代理程式的 SPIFFE 身分、代理程式的執行位置，以及代理程式的任何其他資訊。所有透過 Agent Identity 驗證的 API 要求都會產生代理程式登錄稽核記錄。視代理程式使用的驗證工作流程而定，Cloud 稽核記錄會提供下列資訊：

  • 使用代理程式本身的 ID 進行驗證：產生的稽核記錄會包含代理程式的主體 ID，可用於尋找代理程式的叢集、命名空間和 ServiceAccount。
  • 代表使用者執行的委派作業：產生的稽核記錄包含授權動作的使用者資訊，以及執行呼叫的代理程式 SPIFFE ID。稽核記錄中的身分關聯可協助您驗證使用者是否授權執行特定動作。

除了 Cloud 稽核記錄，應用程式開發人員也可以設定代理程式工作負載，發出 Google Cloud Observability 可見的追蹤記錄、記錄和指標。如要進一步瞭解如何設定工作負載，請參閱下列文件：

提升 GKE 代理程式的安全性

安全管理員可以參照代理程式身分，分別管理代理程式專屬的安全措施，以及其他類型工作負載的限制。執行代理程式時，請考慮採取下列防禦措施：

限制

  • 您只能在 Agent Registry 中自動註冊 Deployment。 其他工作負載控制器和靜態 Pod 不支援自動註冊。
  • 繫結的代理程式身分存取權杖只會使用 https://www.googleapis.com/auth/cloud-platform OAuth 範圍。您無法為繫結的存取權杖指定其他範圍。
  • 只有使用 2.61.0 以上版本 google-auth 程式庫的 Python 應用程式，才支援自動擷取繫結存取權或 ID 權杖。如果您使用 Python 適用的 Cloud 用戶端程式庫，則必須使用包含 google-auth 程式庫 2.61.0 以上版本的版本。
  • 部分 Cloud 用戶端程式庫可能不會自動將要求路由至 mTLS 端點。
  • 如要進行代理程式對代理程式驗證，您只能使用繫結 ID 權杖，在相同代理程式身分信任網域中的代理程式之間進行驗證。

後續步驟