GKE 用エージェント ID について

エージェント ワークロードでは、他のタイプのワークロードとは異なる防御策、アクセス制御、認証ワークフローが必要になることがよくあります。エージェント ID を使用すると、各エージェントに証明済みの有効期間の短い Pod ごとの ID を付与できます。この ID は、エージェント ワークロードを特定し、 Google Cloud全体でこれらのワークロードの動作を追跡して管理するのに役立ちます。このドキュメントでは、他のGoogle Cloud プロダクトとの統合方法、エージェントが使用できる認証タイプ、これらの ID を使用してワークロードを管理する方法など、Google Kubernetes Engine（GKE）でのエージェント ID の仕組みについて説明します。

このドキュメントは、GKE クラスタで実行されるエージェントのセキュリティを改善し、同時に Google Cloud プロダクトとサービスにエージェントを統合したいプラットフォーム管理者とセキュリティ エンジニアを対象としています。

次のトピックについて理解しておく必要があります。

エージェント ID とは

Google Cloud には、ワークロード用のさまざまな ID タイプが用意されています。各 ID タイプは、特定のユースケースとワークロード タイプを対象としています。エージェント ID は、AI エージェント ワークロード用に設計された ID タイプです。Agent Identity を使用するエージェントには、SPIFFE 標準に基づく一意の ID が割り当てられます。この ID はエージェントのライフサイクルにバインドされ、ワークロードをエージェントとして識別し、Agent Registry や Agent Gateway などのさまざまな Gemini Enterprise Agent Platform サービスによって認識されます。ワークロードが実行される場所に関係なく、ワークロードがアクセスするすべてのサービスで、エージェント ID を持つワークロードを追跡して管理できます。エージェント ID を使用するワークロードは、独自の ID を使用するか、エンドユーザーに代わって、MCP サーバー、 Google Cloudの内外のリソース、他のエージェント、エンドポイントに対して認証できます。エージェント ID の詳細については、エージェント ID の概要をご覧ください。

エージェント ID を使用すると、GKE クラスタにデプロイする AI エージェントのセキュリティとガバナンスを強化し、次のようなエージェントの特定のワークフローを有効にできます。

  • GKE のエージェントを Agent Registry や Agent Gateway などのプロダクトと統合します。
  • Identity and Access Management（IAM）ポリシーで、プロジェクト、フォルダ、組織全体のエージェント ワークロードのロールを管理します。
  • クラスタ内のノードと他の Pod に対するエージェントの侵害の影響を軽減します。
  • Agent Identity Auth Manager を使用して、エンドユーザーに代わってエージェントが操作するなどのさまざまな認証ワークフローを設定します。

Workload Identity Federation for GKE との比較

エージェント ID と Workload Identity Federation for GKE の両方で、ワークロードに ID を付与する方法が提供されています。エージェント ID は、AI エージェントに適用される脅威モデルと特定の要件に合わせて設計されているため、さまざまな機能上の違いが生じます。次の表に、これらの違いの概要を示します。

Agent Identity Workload Identity Federation for GKE
エージェント ID アクセス トークンは、Pod ごとの X.509 証明書に暗号的にバインドできます。バインドされたアクセス トークンには mTLS 接続が必要であり、元の Pod の外部で使用すると機能しません。 フェデレーション アクセス トークンは、Pod ID に暗号的にバインドされておらず、非 mTLS 接続で動作し、元の Pod の外部で使用できます。
Agent Identity Auth Manager と統合して、OAuth ワークフローをサポートし、手動で認証情報を管理することなくサードパーティの認証情報を使用します。 外部ツールやサービスに対する認証を行う際に、OAuth ワークフローの手動実装とサードパーティ認証情報の管理が必要になります。
AI エージェントなどの自律型ワークロードに適しています。 ウェブサーバー、API、バッチジョブなどの決定論的マイクロサービスに適しています。
GKE バージョン 1.37.0-gke.3503000 以降が必要です。 すべての GKE バージョンで利用できます。
バインドされたエージェント ID アクセス トークンは、常に https://www.googleapis.com/auth/cloud-platform アクセス スコープを使用します。カスタム スコープはサポートされていません。 連携アクセス トークンは、カスタム アクセス スコープをサポートしています。
アプリケーションは、エージェント ID ID トークンを取得して、他のワークロードまたはダウンストリーム サービスに対して直接認証できます。 Kubernetes ServiceAccount が IAM サービス アカウントの権限を借用するように構成されていない限り、アプリケーションは ID トークンを取得できません。

Agent Platform との統合

Gemini Enterprise Agent Platform には、エージェントの構築、管理、運用を大規模に行うために設計された複数のプロダクトとサービスが含まれています。GKE でエージェント ワークロードを実行する場合は、ワークロードにエージェント ID を割り当て、ワークロードを Agent Registry にエージェントとして登録することで、Agent Platform プロダクトを使用できます。Agent Platform サービスを GKE エージェントと統合して使用するには、アプリケーション オペレーターがエージェント ワークロードの Kubernetes 仕様にアノテーションとラベルを追加します。Workload Identity Federation for GKE が有効になっていることを確認する以外に、クラスタまたはノードプールの構成を変更する必要はありません。これにより、Agent Runtime または Cloud Run で実行されるエージェントを管理する場合と同じ方法で、GKE エージェントを管理および制御できます。

エージェント レジストリに登録すると、組織間でプロジェクトを移動する際の潜在的な中断を防ぐこともできます。プロジェクトの移動中に、エージェント レジストリは、移動後に変更される組織レベルの信頼ドメインに基づくエージェント ID を使用するエージェントがあるかどうかを確認します。組織レベルのエージェント ID が使用されている場合、プロジェクトの移動はブロックされます。このチェックは、Agent Registry に登録した Deployment でのみ行われます。他のワークロード コントローラや静的 Pod ではチェックは行われません。

GKE での仕組み

GKE では、エージェント ID は、Workload Identity Federation for GKE と同様に、GKE メタデータ サーバーや ID プールなどのコンセプトを使用します。エージェント ID を使用するには、クラスタで Workload Identity Federation for GKE も有効にする必要があります。 Google Cloud は、プロジェクトまたは組織レベルでエージェント ID プールを自動的に作成します。エージェント ID プールは SPIFFE 信頼ドメインであり、エージェント ID と認証情報のルート オブ トラストです。アプリケーション デベロッパーは、Pod 仕様にアノテーションとラベルを追加することで、エージェントのエージェント ID をリクエストできます。ワークロードがクラスタにデプロイされると、GKE は次の認証情報をワークロードに割り当てます。

  • ワークロードを識別する SPIFFE ID。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 Namespace の名前。
    • SERVICEACCOUNT_NAME: Pod に割り当てられている Kubernetes ServiceAccount の名前。

  • 各 Pod のボリュームとしてマウントされ、 Google Cloud API への mTLS 認証に使用できるエージェント ID 認証情報バンドル（x509.credential-bundle.private-key.pem）。このファイルには次の認証情報が含まれています。

    • エージェント ワークロードの SPIFFE ID をサブジェクト代替名（SAN）パラメータとして含み、24 時間後に期限切れになる X.509 証明書チェーン。証明書チェーンは、他のサービスに対する認証用のバインドされたアクセス トークンと ID トークンを取得するために使用されます。
    • kubelet プロセスが各 Pod に対して自動的に作成する秘密鍵。鍵は、Pod の X.509 証明書を Pod に暗号的にバインドします。この鍵は、リクエストを行った Pod が TLS 接続の確立に使用された X.509 証明書を所有していることを証明します。

  • 各 Pod のボリュームとしてマウントされ、同じ信頼ドメインを使用するエージェント間の mTLS 認証の構成に使用できるルート CA 信頼バンドル（TRUST_DOMAIN.spiffe-trust-bundle.pem）。mTLS ハンドシェイク中に、エージェントはルート CA 信頼バンドルを使用して、ピア エージェントによって提示された証明書チェーンを検証します。

ワークロード レベルの構成

エージェント ID と Pod ごとの認証情報をワークロードに割り当てるため、GKE は Pod 仕様で次のアノテーションを探します。

  • iam.gke.io/identity: "spiffe://TRUST_DOMAIN/*": GKE はこのアノテーションを使用して、対応する信頼ドメインから Pod に SPIFFE ID を割り当てます。

  • iam.gke.io/inject-podcertificates: "true": GKE はこのアノテーションを使用して、エージェント ID 認証情報バンドルとクラスタ信頼バンドルをワークロード内の各 Pod に追加します。このアノテーションを省略すると、特定の Pod にバインドされたアクセス トークンを取得できません。挿入された認証情報は、Pod からGoogle Cloud APIs またはピア エージェントへの mTLS 認証に使用されます。

また、エージェント レジストリは次のラベルとアノテーションを使用して、GKE エージェントを自動的に登録します。

  • registry.gke.io/functional-type: "AGENT" ラベル: ワークロードを AI エージェントとして識別し、エージェントをエージェント レジストリに追加します。このラベルは Deployment でのみサポートされており、Deployment マニフェストの metadata.labels フィールドで指定する必要があります。
  • iam.gke.io/spiffe-identity-type: "agent-identity" アノテーション: エージェントがエージェント ID を使用することを示します。このアノテーションは、Pod 仕様で指定します。Deployment に registry.gke.io/functional-type: "AGENT" ラベルが指定されている場合、このアノテーションは Pod 仕様で必須です。

GKE エージェントを Agent Platform と統合するには、エージェント ID の使用に加えて、ワークロードを Agent Registry に登録します。エージェント ワークロードの登録を強制するか、デプロイ パイプラインで登録を自動化することを検討してください。

エージェントのアクセス トークン

GKE では、エージェント ID を使用する各 Pod は、X.509 証明書と Pod の秘密鍵を含む一意の認証情報バンドルを取得します。このバンドルは Pod から離れることはありません。 Google Cloud API または外部サービスにアクセスするために、GKE クラスタ内のエージェント Pod は、各ノードで実行されている GKE メタデータ サーバーからエージェント ID アクセス トークンをリクエストします。Pod は、エージェント ID アクセス トークンを使用して、エージェント ID として認証します。

アクセス トークンは、次のようにバインドまたはバインド解除できます。

  • バインドされたアクセス トークン: Pod の X.509 証明書に暗号的にバインドされ、その X.509 証明書を使用して認証された mTLS 接続でのみ使用できます。ペイロードに X.509 証明書を含むアクセス トークン リクエストは、バインドされたトークンになります。
  • バインドされていないアクセス トークン: 特定の Pod に暗号的にバインドされておらず、非 mTLS 接続で使用できます。バインドされていないアクセス トークンは、漏洩したトークンを別の Pod で使用できるため、トークン再生攻撃に対して脆弱です。

エージェントは、バインドされたアクセス トークンまたはバインドされていないアクセス トークンを使用して、Google Cloud APIs へのリクエストを認証します。ID 管理者は、エージェントの Google Cloud リソースへのアクセスを制御するで説明されているように、IAM ポリシーでエージェント ID アクセス トークンのプリンシパル ID を指定することで、エージェントが持つアクセス権を制御できます。

Pod に iam.gke.io/inject-podcertificates: "true" アノテーションがある場合、Cloud クライアント ライブラリと Google 認証ライブラリは アプリケーションのデフォルト認証情報（ADC）を使用して、Pod のバインドされたエージェント ID アクセス トークンを自動的に取得します。この自動プロセスは、すべてのライブラリまたはプログラミング言語で発生するとは限りません。代わりにバインドされていないアクセス トークンをリクエストするには、デベロッパーは次のいずれかの方法を使用します。

  • Pod 仕様で iam.gke.io/inject-podcertificates: "true" アノテーションを指定し、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 のバインドされていないアクセス トークンを取得します。

  • GKE メタデータ サーバーのトークン エンドポイントに直接 HTTP GET リクエストを送信します。これにより、バインドされていないアクセス トークンが返されます。

エージェントの認証ワークフロー

エージェント以外のワークロードとは異なり、エージェントが実行しようとしているタスクによっては、エンドユーザーの代わりに、またはエージェント自身の ID としてサービスに対して認証を行う必要がある場合があります。Agent Identity は、さまざまな認証情報と認証モデルを使用して、次のタイプのリソースに対する認証をサポートしています。

  • Google Cloud API
  • 外部のツールとサービス
  • エージェント間の認証

Google Cloud APIs に対する認証

エージェントは、独自 ID を使用して Google Cloud API（BigQuery や Agent Platform など）に対する認証を行うことができます。認証を行うため、Pod はノードの GKE メタデータ サーバーからエージェント ID アクセス トークンを取得します。このアクセス トークンは、必要に応じて Pod の X.509 証明書にバインドできます。つまり、アクセス トークンは、X.509 証明書を使用して認証された mTLS 接続でのみ使用できます。

アプリケーションで google-auth Python 認証ライブラリのバージョン 2.61.0 以降を使用している場合、アプリケーションのデフォルト認証情報（ADC）は、エージェント ID 認証情報バンドルを持つ Pod のバインドされたアクセス トークンを自動的にリクエストします。Python 用の Cloud クライアント ライブラリを使用する場合は、google-auth ライブラリのバージョン 2.61.0 以降を含むバージョンを使用していることを確認してください。他のプログラミング言語の場合や、google-auth Python ライブラリのバージョンが 2.61.0 より前の場合は、代わりにバインドされていないアクセス トークンをリクエストします。

バインドされたアクセス トークンを取得した場合は、Pod の X.509 証明書を使用して、宛先 API の mTLS エンドポイントとの mTLS 接続を確立する必要があります。バインドされていないアクセス トークンを取得した場合は、そのトークンを API の非 mTLS エンドポイントへのリクエストで使用できます。

これらのメソッドを使用してバインドされたアクセス トークンまたはバインドされていないアクセス トークンを取得するようにアプリケーション コードを構成するには、GKE でエージェント ID を使用して認証するをご覧ください。

プラットフォーム管理者またはセキュリティ管理者の場合は、Google Cloud API に対して認証を行うエージェントに追加の認証を構成する必要はありません。エージェントの Google Cloud リソースへのアクセスを制御するで説明されているように、IAM ポリシーを使用してリソースへのアクセスを制御できます。

外部サービスに対するエージェント認証

エージェントは、API キーや OAuth トークンなどの特定の認証情報を使用して、外部ツールやサービスにアクセスする必要があることがよくあります。エージェントは、独自のアカウントとして認証するか、エンドユーザーのアカウントとして認証する必要がある場合があります。Agent Identity Auth Manager（プレビュー）を使用すると、エージェントに特定の認証情報を指定できます。認証マネージャーは、 Google Cloudで実行するエージェントの認証情報の取得と認証ワークフローの構成を一元化します。

認証マネージャーで、特定の認証ワークフローを処理するように認証プロバイダを構成します。GKE のエージェントが特定認証情報を使用して認証する必要がある場合、Pod はエージェント ID アクセス トークンを使用して認証マネージャーに対する認証を行います。認証プロバイダは、追加の認証手順を処理し、リクエストされた認証情報を Pod に返します。認証マネージャーは外部認証情報を有効期間の短いアクセス トークンと交換するため、有効期間の長い更新トークンと API Secret はエージェント コンテナに保存されません。

認証マネージャーは、次のユースケースで使用できます。各ユースケースでは、認証マネージャーとアプリケーション コードで特定の設定と構成が必要です。

  • エンドユーザーに代わって外部サービスにアクセスします。
  • 独自の ID として外部サービスにアクセスします。
  • API キーを使用して API にアクセスします。

認証マネージャーが作成した認証情報をモニタリングして取り消すことができます。エージェントはエージェント ID アクセス トークンを使用して認証マネージャーに対して認証を行うため、特定のエージェントが使用する認証情報を追跡することもできます。以降のセクションでは、認証マネージャーのユースケースと、対応する認証モデルについて説明します。使用する認証モデルに応じて、エージェント コードとクライアントサイド アプリケーションに特定の変更を加える必要があります。

エンドユーザーに代わって外部サービスにアクセスする

エンドユーザーは、Slack チャンネルにメッセージを投稿したり、GitHub リポジトリで pull リクエストを開くなど、ユーザーに代わって特定のアクションを実行するようエージェントに依頼することがあります。このようなシナリオでは、ユーザーがエージェントに代行を明示的に同意することで、エージェントに権限を委任します。ユーザーの同意と認証情報の取得を設定するには、3-legged OAuth を使用します。これには次の手順が含まれます。

  1. 認証プロバイダは、外部サービスに対して認証を行うようユーザーをリダイレクトします。
  2. ユーザーがログインし、エージェントが必要とするアクセス権を承認します。
  3. 外部サービスが認証情報を認証プロバイダに返します。

GKE で実行されるエージェントの 3 レッグ OAuth を構成するには、プラットフォーム管理者とアプリケーション デベロッパーが次の手順を行います。

  1. プラットフォーム管理者が認証プロバイダを設定します。
    1. 認証マネージャーで 3-legged OAuth 認証プロバイダを作成します。
    2. サードパーティの認証サーバーにリダイレクトするように認証プロバイダを構成します。
    3. ユーザー アクセス トークンを認証プロバイダに送信するようにサードパーティ サービスを構成します。
    4. 認証プロバイダにアクセスする権限をエージェントに付与します。
  2. アプリケーション デベロッパーがアプリケーションを変更します。
    1. 認証プロバイダを使用して認証を行うようにエージェント コードを変更します。
    2. ユーザーのログイン、リダイレクト、会話の再開を処理するようにクライアントサイドのアプリケーション コードを変更します。

認証プロバイダを構成し、エージェントとクライアントサイド アプリケーションを変更する方法については、認証マネージャーで 3-legged OAuth を使用して認証するをご覧ください。

エージェント ID としての外部サービスへのアクセス

エージェントは、エージェント自身の ID を使用して ServiceNow や Salesforce などの外部サービスにアクセスする必要がある場合があります。たとえば、広告在庫管理エージェントは、販売データをモニタリングし、注文在庫を管理して、ピーク時のセールイベントで在庫切れが発生しないようにします。このようなシナリオでは、2 レッグ OAuth を使用します。これには次の手順が含まれます。

  1. 認証マネージャーが外部サービスにアクセス トークンをリクエストします。
  2. 外部サービスがリクエストを検証し、認証マネージャーにアクセス トークンを返します。

GKE で実行されるエージェントに 2 レッグ OAuth を構成するには、次の操作を行います。

  1. プラットフォーム管理者が認証プロバイダを設定します。
    1. 外部サービスから OAuth クライアント ID、クライアント シークレット、トークン エンドポイントを取得します。
    2. 外部サービスの OAuth 情報を含む 2-legged OAuth 認証プロバイダを認証マネージャーに作成します。
    3. 認証プロバイダにアクセスする権限をエージェントに付与します。
  2. アプリケーション デベロッパーは、認証プロバイダを使用して認証を行うようにエージェント コードを変更します。

認証プロバイダを構成してエージェント コードを変更する方法については、認証マネージャーで 2 レッグ OAuth を使用して認証するをご覧ください。

API キーを使用して API にアクセスする

エージェントが外部 API の認証に使用する API キーを認証マネージャーに保存できます。API キーは Secret Manager などの他の Vault に保存できますが、認証マネージャー メソッドを使用すると、エージェントによる API キーへのアクセスを一元的に追跡して管理できます。認証マネージャーで API キーを保存して使用するには、次の操作を行います。

  1. プラットフォーム管理者が認証プロバイダを設定します。
    1. 認証マネージャーで API キー認証プロバイダを作成します。
    2. API キーを生成して認証プロバイダに保存します。
    3. 認証プロバイダにアクセスする権限をエージェントに付与します。
  2. 認証プロバイダを使用して認証を行うようにエージェント コードを変更します。

詳細については、認証マネージャーで API キーを使用して認証するをご覧ください。

エージェント間の認証

このセクションでは、高度な認証ワークフローについて説明します。次のトピックについて理解しておく必要があります。

  • JSON Web Token（JWT）: エージェント ID トークンは署名付き JWT です。
  • JSON Object Signing and Encryption（JOSE）ヘッダー: ID トークンには、ID トークンのアルゴリズムと署名鍵を記述する JOSE ヘッダーがあります。
  • JSON ウェブキー（JWK）: JWK は ID トークンの署名に使用されます。エージェント ID プールの公開 JWK は、JSON Web Key Set（JWKS）として公開されます。これらの公開鍵を使用して、他のエージェントから受信した ID トークンを検証します。

マルチエージェント アーキテクチャでは、エージェントはピア エージェントまたはダウンストリーム サービスを直接呼び出すことで頻繁に連携します。エージェント ワークロード間の通信は、エージェント ID ID トークンを使用して直接確立できます。これは、GKE メタデータ サーバーから取得できる署名付き JWT です。エージェント サービス間の接続を認証するには、アプリケーション デベロッパーは次の操作を行います。

  1. 呼び出し元エージェントの GKE メタデータ サーバーからエージェント ID トークンを取得します。この ID トークンでは、aud クレームを受信エージェントのエンドポイントに設定する必要があります。
  2. HTTP リクエストの Authorization: Bearer リクエスト ヘッダーに ID トークンを含めます。
  3. 受信エージェントで、エージェント ID プールの公開 JWK と ID トークンのさまざまなヘッダー パラメータと本文パラメータを使用して、受信した ID トークンを検証します。

アプリケーション コードで ID トークンをリクエスト、使用、検証する方法については、他のエージェントに対して認証するをご覧ください。

このワークフローでは IAM 認可チェックがバイパスされるため、エージェント間の認証ではプラットフォーム管理者の追加の Google Cloud構成は必要ありません。代わりに、エージェントは互いに直接通信し、エージェント ID に基づいてアクションを承認します。

エージェントの Google Cloud リソースへのアクセスを制御する

セキュリティ管理者は、エージェントのプリンシパル ID を参照する IAM ポリシーを使用して、エージェントがアクセスできるリソースを制御できます。GKE で実行され、エージェント ID を持つエージェントのリソースへのアクセスを制御するには、IAM ポリシーに次のいずれかのプリンシパル ID を含めます。

  • 特定の信頼ドメイン内のすべてのエージェント:

    principalSet://TRUST_DOMAIN/*

    この識別子では、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

    この識別子では、次のパラメータが特定のエージェントを識別します。

    • PROJECT_NUMBER: クラスタのプロジェクトのプロジェクト番号。
    • CONTROL_PLANE_LOCATION: クラスタ コントロール プレーンのリージョンまたはゾーン。
    • CLUSTER_NAME: エージェントが存在するクラスタの名前。
    • NAMESPACE_NAME: エージェントが存在する Kubernetes Namespace の名前。
    • SERVICEACCOUNT_NAME: エージェント ワークロードが使用する Kubernetes ServiceAccount の名前。

GKE エージェントのプリンシパル ID を見つけてアクセスを管理する方法については、エージェントの Google Cloud API へのアクセスを管理するをご覧ください。

Agent Identity は、許可ポリシー、拒否ポリシー、プリンシパル アクセス境界（PAB）ポリシーなど、すべての IAM ポリシータイプをサポートしています。エージェント ID を使用する GKE クラスタ内のエージェントのアクセスを管理するには、対応するポリシータイプにエージェントのプリンシパル ID を含めます。各タイプの IAM ポリシーの構成方法の詳細については、次のトピックをご覧ください。

Google Cloud全体でエージェントを表示して管理する

アプリケーション デベロッパーがエージェントをエージェント レジストリに登録すると、 Google Cloudで実行する他のエージェントとともに GKE エージェントを表示できます。Agent Registry には、エージェントの SPIFFE ID、エージェントが実行される場所、エージェントに関する追加情報が表示されます。Agent Identity を使用して認証されたすべての API リクエストは、Agent Registry 監査ログを生成します。エージェントが使用する認証ワークフローに応じて、Cloud Audit Logs は次の情報を提供します。

  • エージェント独自の ID を使用した認証: 生成された監査ログにはエージェントのプリンシパル ID が含まれます。これを使用して、エージェントのクラスタ、Namespace、ServiceAccount を見つけることができます。
  • エンドユーザーに代わって委任されたオペレーション: 生成された監査ログには、アクションを承認したエンドユーザーと、呼び出しを実行したエージェントの SPIFFE ID に関する情報が含まれます。監査ログのこの ID 関連付けは、エンドユーザーが特定のアクションを承認したことを検証するのに役立ちます。

Cloud Audit Logs に加えて、アプリケーション デベロッパーは、Google Cloud Observability で表示されるトレース、ログ、指標を生成するようにエージェント ワークロードを構成できます。ワークロードの構成方法の詳細については、次のドキュメントをご覧ください。

GKE エージェントのセキュリティを強化する

セキュリティ管理者は、エージェント ID を参照することで、他のタイプのワークロードの制約とは別に、エージェント固有のセキュリティ対策を管理できます。エージェントを実行する際の防御策として、次の点を考慮してください。

制限事項

  • Agent Registry に自動的に登録できるのは、Deployment のみです。他のワークロード コントローラと静的 Pod は自動登録をサポートしていません。
  • バインドされたエージェント ID アクセス トークンは、https://www.googleapis.com/auth/cloud-platform OAuth スコープのみを使用します。バインドされたアクセス トークンに別のスコープを指定することはできません。
  • バインドされたアクセス トークンまたは ID トークンの自動取得は、google-auth ライブラリのバージョン 2.61.0 以降を使用する Python アプリケーションでのみサポートされています。Python 用 Cloud クライアント ライブラリを使用する場合は、google-auth ライブラリのバージョン 2.61.0 以降を含むバージョンを使用する必要があります。
  • 一部の Cloud クライアント ライブラリでは、リクエストが mTLS エンドポイントに自動的に転送されない場合があります。
  • エージェント間の認証では、バインドされた ID トークンを使用して、同じエージェント ID 信頼ドメイン内のエージェント間で認証を行うことができます。

次のステップ