Agent Identity for GKE

Für Agent-Arbeitslasten sind oft andere Schutzmaßnahmen, Zugriffssteuerungen und Authentifizierungsabläufe als für andere Arten von Arbeitslasten erforderlich. Mit Agent Identity können Sie jedem Agenten eine bestätigte, kurzlebige Identität pro Pod zuweisen. Mit dieser Identität können Sie Agent-Arbeitslasten identifizieren und nachverfolgen und verwalten, was diese Arbeitslasten in Google Cloudtun. In diesem Dokument wird beschrieben, wie die Agent-Identität in Google Kubernetes Engine (GKE) funktioniert, einschließlich der Integration mit anderenGoogle Cloud -Produkten, der Arten der Authentifizierung, die Ihre Agents verwenden können, und wie Sie Ihre Arbeitslasten mithilfe dieser Identitäten verwalten.

Dieses Dokument richtet sich an Plattformadministratoren und Sicherheitstechniker, die die Sicherheit von Agents verbessern möchten, die in GKE-Clustern ausgeführt werden, und gleichzeitig die Agents in Google Cloud -Produkte und ‑Dienste einbinden möchten.

Sie sollten bereits mit den folgenden Themen vertraut sein:

Was ist die Agentenidentität?

Google Cloud bietet verschiedene Identitätstypen für Ihre Arbeitslasten, die jeweils für bestimmte Anwendungsfälle und Arbeitslasttypen vorgesehen sind. Die Identität des KI-Agenten ist ein Identitätstyp, der für Arbeitslasten von KI-Agenten konzipiert ist. Ein KI-Agent, der die Agent-Identität verwendet, erhält eine eindeutige Identität, die auf dem SPIFFE-Standard basiert. Diese Identität ist an den Lebenszyklus des Agents gebunden, identifiziert den Workload als Agent und wird von den verschiedenen Diensten der Gemini Enterprise Agent Platform wie Agent Registry und Agent Gateway erkannt. Sie können eine Arbeitslast mit einer Agentenidentität in allen Diensten, auf die die Arbeitslast zugreift, nachverfolgen und verwalten, unabhängig davon, wo die Arbeitslast ausgeführt wird. Eine Arbeitslast, die die Agent-Identität verwendet, kann sich mit ihrer eigenen Identität oder im Namen eines Endnutzers bei MCP-Servern, Ressourcen innerhalb und außerhalb von Google Cloud, anderen Agents und Endpunkten authentifizieren. Weitere Informationen zur Agent-Identität finden Sie unter Agent-Identität – Übersicht.

Mit der Agent-Identität können Sie die Sicherheit und Governance für KI-Agents verbessern, die Sie in GKE-Clustern bereitstellen, und bestimmte Workflows für Ihre Agents aktivieren, z. B.:

  • Agenten in GKE mit Produkten wie Agent Registry und Agent Gateway integrieren
  • Rollen für Agent-Arbeitslasten in Projekten, Ordnern oder Organisationen in IAM-Richtlinien (Identity and Access Management) verwalten.
  • Die Auswirkungen von kompromittierten Agents auf Knoten und andere Pods im Cluster werden reduziert.
  • Mit dem Authentifizierungsmanager für die Identität von KI-Agenten können Sie verschiedene Authentifizierungsabläufe einrichten, z. B. für Agenten, die im Namen von Endnutzern agieren.

Vergleich mit Workload Identity Federation for GKE

Sowohl Agent Identity als auch Workload Identity Federation for GKE bieten Möglichkeiten, Arbeitslasten Identitäten zuzuweisen. Die Agent-Identität ist für das Bedrohungsmodell und die spezifischen Anforderungen konzipiert, die für KI-Agents gelten. Dies führt zu verschiedenen funktionalen Unterschieden. Die folgende Tabelle bietet einen allgemeinen Vergleich dieser Unterschiede:

Agent Identity Workload Identity Federation for GKE
Zugriffstokens für Agentenidentitäten können kryptografisch an X.509-Zertifikate pro Pod gebunden werden. Für ein gebundenes Zugriffstoken ist eine mTLS-Verbindung erforderlich. Es funktioniert nicht, wenn es außerhalb des ursprünglichen Pods verwendet wird. Föderierte Zugriffstokens sind nicht kryptografisch an Pod-Identitäten gebunden, funktionieren über Nicht-mTLS-Verbindungen und können außerhalb des ursprünglichen Pods verwendet werden.
Wird in den Auth-Manager für die Agent-Identität eingebunden, um OAuth-Abläufe zu unterstützen und Anmeldedaten von Drittanbietern ohne manuelle Verwaltung von Anmeldedaten zu verwenden. Erfordert die manuelle Implementierung von OAuth-Abläufen und die Verwaltung von Drittanbieteranmeldedaten bei der Authentifizierung bei externen Tools und Diensten.
Funktioniert gut für autonome Arbeitslasten wie KI-Agents. Funktioniert gut für deterministische Mikrodienste wie Webserver, APIs und Batchjobs.
Erfordert GKE-Version 1.37.0-gke.3503000 oder höher. In allen GKE-Versionen verfügbar.
Für Zugriffstokens für gebundene Agentenidentitäten wird immer der Zugriffsbereich https://www.googleapis.com/auth/cloud-platform verwendet. Benutzerdefinierte Bereiche werden nicht unterstützt. Föderierte Zugriffstokens unterstützen benutzerdefinierte Zugriffsbereiche.
Anwendungen können Agent-Identitäts-ID-Tokens abrufen, um sich direkt bei anderen Arbeitslasten oder nachgelagerten Diensten zu authentifizieren. Anwendungen können keine ID-Tokens abrufen, wenn das Kubernetes-Dienstkonto nicht so konfiguriert ist, dass es die Identität eines IAM-Dienstkontos übernimmt.

Einbindung in die Agent Platform

Die Gemini Enterprise Agent Platform umfasst mehrere Produkte und Dienste, die für die Entwicklung, Verwaltung und den Betrieb von Agenten im großen Maßstab konzipiert sind. Wenn Sie Agent-Arbeitslasten in GKE ausführen, können Sie die Agent Platform-Produkte verwenden, indem Sie den Arbeitslasten Agent-Identitäten zuweisen und die Arbeitslasten als Agents in der Agent Registry registrieren. Damit Sie Agent Platform-Dienste in Ihre GKE-Agents einbinden und verwenden können, fügen Ihre Anwendungsoperatoren Annotationen und Labels zu den Kubernetes-Spezifikationen der Agent-Arbeitslasten hinzu. Außer der Überprüfung, ob Workload Identity Federation for GKE aktiviert ist, müssen Sie keine Änderungen an der Cluster- oder Knotenpoolkonfiguration vornehmen. Sie können Ihre GKE-Agenten dann auf dieselbe Weise verwalten und steuern wie einen Agenten, der in Agent Runtime oder in Cloud Run ausgeführt wird.

Die Registrierung in der Agent Registry trägt auch dazu bei, potenzielle Unterbrechungen zu vermeiden, wenn Sie Projekte zwischen Organisationen verschieben. Während der Projektmigration prüft die Agent Registry, ob für Agents eine Agent Identity verwendet wird, die auf der Vertrauensdomäne auf Organisationsebene basiert. Diese würde sich nach der Migration ändern. Wenn eine Agentenidentität auf Organisationsebene verwendet wird, wird die Projektmigration blockiert. Diese Prüfung erfolgt nur bei Bereitstellungen, die Sie in der Agent Registry registrieren. Die Prüfung erfolgt nicht bei anderen Workload-Controllern oder statischen Pods.

Funktionsweise in GKE

In GKE verwendet die Agent-Identität Konzepte wie den GKE-Metadatenserver und Identitätspools, ähnlich wie Workload Identity Federation for GKE. Wenn Sie Agent Identity verwenden möchten, müssen Sie auch Workload Identity Federation for GKE im Cluster aktivieren. Google Cloud erstellt automatisch einen Agent-Identitätspool auf Projekt- oder Organisationsebene. Der Agent-Identitätspool ist eine SPIFFE-Vertrauensdomäne und der Root of Trust für Agent-Identitäten und ‑Anmeldedaten. Anwendungsentwickler können eine Agent-Identität für ihren Agent anfordern, indem sie ihrer Pod-Spezifikation Anmerkungen und Labels hinzufügen. Wenn die Arbeitslast in einem Cluster bereitgestellt wird, weist GKE der Arbeitslast die folgenden Anmeldedaten zu:

  • Eine SPIFFE-Identität, die die Arbeitslast identifiziert. Alle Pods in einer verwalteten Arbeitslast, z. B. einem Deployment, haben die SPIFFE-ID dieser Arbeitslast. Die SPIFFE-ID identifiziert den Agenten über Google Cloud Dienste hinweg. Sie können alle Aktionen, die die Pods ausführen, unabhängig davon, ob sie als Agent oder im Namen eines Endnutzers erfolgen, anhand der SPIFFE-ID nachverfolgen. Die SPIFFE-ID hat die folgende Syntax:

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

    Dieser ID-String hat die folgenden Attribute:

    • TRUST_DOMAIN: die SPIFFE-Vertrauensdomäne, die einen der folgenden Werte hat, je nachdem, ob sich das Projekt, das den Cluster enthält, in einer Organisation befindet oder nicht:
      • Projekte in einer Organisation: agents.global.org-ORGANIZATION_ID.system.id.goog, wobei ORGANIZATION_ID die ID der Organisation ist.
      • Projekte, die sich nicht in einer Organisation befinden: agents.global.proj-PROJECT_NUMBER.system.id.goog, wobei PROJECT_NUMBER die Projektnummer des Clusterprojekts ist.
    • PROJECT_NUMBER: die Projektnummer des Clusterprojekts.
    • CONTROL_PLANE_LOCATION: Die Region oder Zone, in der sich die Steuerungsebene des Clusters befindet.
    • CLUSTER_NAME: der Name des Clusters, in dem sich der Pod befindet.
    • NAMESPACE: der Name des Kubernetes-Namespace, in dem sich der Pod befindet.
    • SERVICEACCOUNT_NAME: der Name des Kubernetes-Dienstkontos, das dem Pod zugewiesen ist.

  • Ein Bündel mit Berechtigungsnachweisen für die Identität des KI-Agenten (x509.credential-bundle.private-key.pem), das als Volume in jedem Pod bereitgestellt wird und für die mTLS-Authentifizierung bei Google Cloud APIs verwendet werden kann. Diese Datei enthält die folgenden Anmeldedaten:

    • Eine X.509-Zertifikatskette, die die SPIFFE-ID für die Agent-Arbeitslast als SAN-Parameter (Subject Alternative Name, alternativer Antragstellername) enthält und in 24 Stunden abläuft. Die Zertifikatskette wird verwendet, um gebundene Zugriffstokens und Identitätstokens für die Authentifizierung bei anderen Diensten abzurufen.
    • Ein privater Schlüssel, der vom kubelet-Prozess automatisch für jeden Pod erstellt wird. Der Schlüssel bindet das X.509-Zertifikat eines Pods kryptografisch an den Pod. Dieser Schlüssel beweist, dass der Pod, der eine Anfrage gestellt hat, das X.509-Zertifikat besitzt, das zum Herstellen der TLS-Verbindung verwendet wurde.

  • Ein Stammzertifizierungsstellen-Vertrauensbündel (TRUST_DOMAIN.spiffe-trust-bundle.pem), das als Volume in jedem Pod bereitgestellt wird und zur Konfiguration der mTLS-Authentifizierung zwischen Agents verwendet werden kann, die dieselbe Vertrauensdomäne verwenden. Während des mTLS-Handshake verwendet ein Agent das Root-CA-Trust-Bundle, um die Zertifikatskette zu validieren, die von einem Peer-Agent präsentiert wird.

Konfiguration auf Arbeitslastebene

Um einer Arbeitslast eine Agent-Identität und Anmeldedaten pro Pod zuzuweisen, sucht GKE in der Pod-Spezifikation nach den folgenden Annotationen:

  • iam.gke.io/identity: "spiffe://TRUST_DOMAIN/*": GKE verwendet diese Annotation, um den Pods eine SPIFFE-ID aus der entsprechenden vertrauenswürdigen Domain zuzuweisen.

  • iam.gke.io/inject-podcertificates: "true": GKE verwendet diese Annotation, um das Anmeldedaten-Bundle für die Agent-Identität und das Cluster-Vertrauensbundle jedem Pod in der Arbeitslast hinzuzufügen. Wenn diese Annotation weggelassen wird, können Sie keine Zugriffstokens abrufen, die an bestimmte Pods gebunden sind. Die eingefügten Anmeldedaten werden für die mTLS-Authentifizierung von Ihren Pods bei allenGoogle Cloud -APIs oder Peer-Agents verwendet.

Außerdem verwendet die Agent Registry das folgende Label und die folgende Annotation, um Ihre GKE-Agents automatisch zu registrieren:

  • registry.gke.io/functional-type: "AGENT"-Label: Identifiziert den Workload als KI-Agenten und fügt den Agenten der Agent Registry hinzu. Dieses Label wird nur von Bereitstellungen unterstützt und muss im Feld metadata.labels des Bereitstellungsmanifests angegeben werden.
  • iam.gke.io/spiffe-identity-type: "agent-identity"-Hinweis: Gibt an, dass der Agent die Agent-Identität verwendet. Diese Annotation wird in der Pod-Spezifikation angegeben. Wenn das Label registry.gke.io/functional-type: "AGENT" für eine Bereitstellung angegeben ist, ist diese Annotation in der Pod-Spezifikation erforderlich.

Wenn Sie Ihre GKE-Agents in die Agent Platform einbinden möchten, müssen Sie Ihre Arbeitslasten zusätzlich zur Verwendung der Agent-Identität in der Agent Registry registrieren. Erwägen Sie, die Registrierung von Agent-Arbeitslasten zu erzwingen oder die Registrierung in Ihrer Bereitstellungspipeline zu automatisieren.

Zugriffstokens für KI-Agenten

In GKE erhält jeder Pod, der die Agent-Identität verwendet, ein eindeutiges Anmeldedatenpaket, das das X.509-Zertifikat und den privaten Schlüssel des Pods enthält. Dieses Paket verlässt den Pod nicht. Um auf Google Cloud APIs oder externe Dienste zuzugreifen, fordert ein Agent-Pod in einem GKE-Cluster ein Zugriffstoken für die Agent-Identität vom GKE-Metadatenserver an, der auf jedem Knoten ausgeführt wird. Der Pod verwendet das Zugriffstoken der Agentenidentität, um sich als Agentenidentität zu authentifizieren.

Das Zugriffstoken kann so gebunden oder ungebunden sein:

  • Gebundenes Zugriffstoken: kryptografisch an das X.509-Zertifikat des Pod gebunden und kann nur über mTLS-Verbindungen verwendet werden, die mit diesem X.509-Zertifikat authentifiziert wurden. Jede Anfrage für ein Zugriffstoken, die das X.509-Zertifikat in der Nutzlast enthält, führt zu einem gebundenen Token.
  • Nicht gebundenes Zugriffstoken: nicht kryptografisch an einen bestimmten Pod gebunden und kann über Nicht-mTLS-Verbindungen verwendet werden. Ungebundene Zugriffstokens sind anfälliger für Token-Replay-Angriffe, da ein geleaktes Token von einem anderen Pod verwendet werden kann.

Kundenservicemitarbeiter verwenden die gebundenen oder ungebundenen Zugriffstokens, um ihre Anfragen anGoogle Cloud -APIs zu authentifizieren. Identitätsadministratoren können den Zugriff eines Agents steuern, indem sie die Prinzipal-ID des Zugriffstokens der Agentenidentität in IAM-Richtlinien angeben, wie unter Zugriff auf Google Cloud Ressourcen für Agents steuern beschrieben.

Wenn Pods die Annotation iam.gke.io/inject-podcertificates: "true" haben, verwenden die Cloud-Clientbibliotheken und Google-Authentifizierungsbibliotheken Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC), um automatisch ein Zugriffstoken für die gebundene Agent-Identität für Pods abzurufen. Dieser automatische Prozess wird möglicherweise nicht in jeder Bibliothek oder Programmiersprache ausgeführt. Um stattdessen nicht gebundene Zugriffstokens anzufordern, verwenden Entwickler eine der folgenden Methoden:

  • Geben Sie die Annotation iam.gke.io/inject-podcertificates: "true" an und legen Sie die Umgebungsvariable GOOGLE_API_ENABLE_RUNTIME_BOUND_TOKEN in der Pod-Spezifikation auf den Wert false fest. GKE fügt dem Pod das X.509-Anmeldedaten-Bundle hinzu, aber die Umgebungsvariable bewirkt, dass ADC ungebundene Zugriffstokens abruft.

    Mit dieser Methode können die Pods weiterhin mTLS-Verbindungen zu anderen Arbeitslasten herstellen, indem sie die Zertifikate verwenden. Gleichzeitig können sie mit nicht gebundenen Zugriffstokens auf Google Cloud APIs zugreifen.

  • Geben Sie die Annotation iam.gke.io/inject-podcertificates: "true" nicht in der Pod-Spezifikation an. GKE fügt das X.509-Anmeldedatenpaket nicht dem Pod hinzu, sodass ADC ungebundene Zugriffstokens für die Pods erhält.

  • Senden Sie eine direkte HTTP-GET-Anfrage an den Tokenendpunkt des GKE-Metadatenservers, der ein nicht gebundenes Zugriffstoken zurückgibt.

Authentifizierungsworkflows für Agents

Im Gegensatz zu Workloads ohne Agent müssen sich Agents möglicherweise im Namen eines Endnutzers oder als eigene Identität beim Dienst authentifizieren, je nachdem, welche Aufgabe der Agent ausführt. Die Agent-Identität unterstützt die Authentifizierung für die folgenden Ressourcentypen mit verschiedenen Anmeldedaten und Authentifizierungsmodellen:

  • Google Cloud -APIs
  • Externe Tools und Dienste
  • Authentifizierung von Agent zu Agent

Authentifizierung bei Google Cloud APIs

Ein Agent kann seine eigene Identität verwenden, um sich bei Google Cloud -APIs wie BigQuery oder Agent Platform zu authentifizieren. Zur Authentifizierung ruft der Pod ein Zugriffstoken für die Agent-Identität vom GKE-Metadatenserver auf dem Knoten ab. Dieses Zugriffstoken kann optional an das X.509-Zertifikat des Pods gebunden werden. Das bedeutet, dass das Zugriffstoken nur über eine mTLS-Verbindung verwendet werden kann, die mit dem X.509-Zertifikat authentifiziert wird.

Wenn Ihre Anwendung Version 2.61.0 oder höher der google-auth-Python-Authentifizierungsbibliothek verwendet, werden mit den Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) automatisch gebundene Zugriffstokens für Pods angefordert, die das Anmeldedatenpaket für die Agent-Identität haben. Wenn Sie die Cloud-Clientbibliotheken für Python verwenden, muss die Version, die Sie verwenden, Version 2.61.0 oder höher der google-auth-Bibliothek enthalten. Für andere Programmiersprachen oder für Versionen der google-auth-Python-Bibliothek, die älter als 2.61.0 sind, sollten Sie stattdessen nicht gebundene Zugriffstokens anfordern.

Wenn Sie ein gebundenes Zugriffstoken erhalten, müssen Sie das X.509-Zertifikat des Pods verwenden, um eine mTLS-Verbindung mit dem mTLS-Endpunkt der Ziel-API herzustellen. Wenn Sie ein nicht gebundenes Zugriffstoken erhalten, können Sie es in Anfragen an den Nicht-mTLS-Endpunkt dieser API verwenden.

Informationen zum Konfigurieren Ihres Anwendungscodes, um gebundene oder ungebundene Zugriffstokens mit diesen Methoden abzurufen, finden Sie unter Mit einer Agent-Identität in GKE authentifizieren.

Wenn Sie Plattformadministrator oder Sicherheitsadministrator sind, müssen Sie keine zusätzliche Authentifizierung für Agents konfigurieren, die sich beiGoogle Cloud -APIs authentifizieren. Sie können den Zugriff auf Ressourcen mit IAM-Richtlinien steuern, wie unter Zugriff auf Google Cloud -Ressourcen für Agents steuern beschrieben.

Agent-Authentifizierung bei externen Diensten

KI-Agenten müssen häufig mit bestimmten Anmeldedaten wie API-Schlüsseln oder OAuth-Tokens auf externe Tools und Dienste zugreifen. Der Agent muss sich möglicherweise mit seiner eigenen Identität oder im Namen eines Endnutzers authentifizieren. Sie können Agents bestimmte Anmeldedaten zur Verfügung stellen, indem Sie den Agent Identity Auth Manager (Vorschau) verwenden. Der Auth-Manager zentralisiert die Konfiguration des Workflows für den Abruf von Anmeldedaten und die Authentifizierung für Agents, die Sie in Google Cloudausführen.

Im Auth-Manager konfigurieren Sie Auth-Anbieter, um bestimmte Authentifizierungs-Workflows zu verarbeiten. Wenn sich ein Agent in GKE mit bestimmten Anmeldedaten authentifizieren muss, verwendet der Pod sein Agent-Identitätszugriffstoken, um sich beim Auth-Manager zu authentifizieren. Der Authentifizierungsanbieter führt dann alle zusätzlichen Authentifizierungsschritte aus und gibt die angeforderte Anmeldedaten an den Pod zurück. Der Authentifizierungsmanager tauscht die externen Anmeldedaten gegen kurzlebige Zugriffstokens ein, sodass keine langlebigen Aktualisierungstokens und API-Secrets im Agent-Container gespeichert werden.

Sie können den Auth-Manager für die folgenden Anwendungsfälle verwenden, die jeweils eine bestimmte Einrichtung und Konfiguration im Auth-Manager und im Anwendungscode erfordern:

  • Im Namen eines Endnutzers auf externe Dienste zugreifen
  • Auf externe Dienste mit eigener Identität zugreifen.
  • Über einen API-Schlüssel auf APIs zugreifen

Sie können die vom Autorisierungsmanager erstellten Anmeldedaten überwachen und widerrufen. Sie können auch nachvollziehen, welche Anmeldedaten bestimmte Kundenservicemitarbeiter verwenden, da sich der Kundenservicemitarbeiter mit seinem Zugriffstoken für die Identität des Kundenservicemitarbeiters beim Auth Manager authentifiziert. In den folgenden Abschnitten werden die Anwendungsfälle für den Auth-Manager und die entsprechenden Authentifizierungsmodelle beschrieben. Je nach verwendetem Authentifizierungsmodell müssen Sie und Ihre Anwendungsentwickler bestimmte Änderungen am Agent-Code und an clientseitigen Anwendungen vornehmen.

Zugriff auf externe Dienste im Namen eines Endnutzers

Ein Endnutzer kann einen Agenten bitten, bestimmte Aktionen in seinem Namen auszuführen, z. B. Nachrichten in einem Slack-Kanal zu schreiben oder eine Pull-Anfrage in einem GitHub-Repository zu öffnen. In diesen Szenarien delegiert der Nutzer seine Berechtigung an den Kundenservicemitarbeiter, indem er ausdrücklich zustimmt, dass der Kundenservicemitarbeiter in seinem Namen handelt. Um die Nutzereinwilligung und den Abruf von Anmeldedaten einzurichten, verwenden Sie dreibeiniges OAuth. Das umfasst die folgenden Schritte:

  1. Der Authentifizierungsanbieter leitet den Nutzer zur Authentifizierung an den externen Dienst weiter.
  2. Der Nutzer meldet sich an und genehmigt den Zugriff, den der KI-Agent benötigt.
  3. Der externe Dienst gibt Anmeldedaten an den Authentifizierungsanbieter zurück.

So konfigurieren Sie 3-Legged OAuth für einen Agenten, der in GKE ausgeführt wird:

  1. Der Plattformadministrator richtet den Authentifizierungsanbieter ein:
    1. Erstellen Sie im Authentifizierungsmanager einen Authentifizierungsanbieter für dreibeiniges OAuth.
    2. Konfigurieren Sie den Authentifizierungsanbieter so, dass er zum Autorisierungsserver des Drittanbieters weiterleitet.
    3. Konfigurieren Sie den Drittanbieterdienst so, dass das Nutzerzugriffstoken an den Authentifizierungsanbieter gesendet wird.
    4. KI‑Agenten Zugriff auf den Authentifizierungsanbieter gewähren
  2. Der Anwendungsentwickler ändert die Anwendung:
    1. Ändern Sie den Agent-Code, um die Authentifizierung über den Authentifizierungsanbieter zu ermöglichen.
    2. Ändern Sie den clientseitigen Anwendungscode, um die Nutzeranmeldung, die Weiterleitung und die Wiederaufnahme von Unterhaltungen zu verarbeiten.

Weitere Informationen zum Konfigurieren des Authentifizierungsanbieters und zum Ändern von Agent- und clientseitigen Anwendungen finden Sie unter Mit dreibeinigem OAuth und dem Auth-Manager authentifizieren.

Zugriff auf externe Dienste als KI-Agenten-Identität

Ein Agent muss möglicherweise mit der eigenen Identität des Agents auf externe Dienste wie ServiceNow oder Salesforce zugreifen. Ein Agent für die Inventarverwaltung kann beispielsweise Verkaufsdaten im Blick behalten und Bestände bestellen, um Probleme mit dem Lagerbestand während umsatzstarker Ereignisse zu vermeiden. In diesen Szenarien verwenden Sie 2-legged OAuth (OAuth mit zwei Schritten), das die folgenden Schritte umfasst:

  1. Der Authentifizierungsmanager fordert ein Zugriffstoken vom externen Dienst an.
  2. Der externe Dienst validiert die Anfrage und gibt das Zugriffstoken an den Auth-Manager zurück.

So konfigurieren Sie 2-legged OAuth für einen Agenten, der in GKE ausgeführt wird:

  1. Der Plattformadministrator richtet den Authentifizierungsanbieter ein:
    1. Rufen Sie eine OAuth-Client-ID, einen Clientschlüssel und einen Token-Endpunkt vom externen Dienst ab.
    2. Erstellen Sie im Authentifizierungsmanager einen Authentifizierungsanbieter für zweibeiniges OAuth, der die OAuth-Informationen des externen Dienstes enthält.
    3. KI‑Agenten Zugriff auf den Authentifizierungsanbieter gewähren
  2. Der Anwendungsentwickler ändert den Agent-Code, um die Authentifizierung über den Authentifizierungsanbieter durchzuführen.

Weitere Informationen zum Konfigurieren des Authentifizierungsanbieters und zum Ändern des Agent-Codes finden Sie unter Mit dem Authentifizierungsmanager über 2-legged OAuth authentifizieren.

Zugriff auf APIs über einen API-Schlüssel

Sie können API-Schlüssel im Auth Manager speichern, damit Agents sie zur Authentifizierung bei externen APIs verwenden können. Sie können API-Schlüssel zwar auch in anderen Tresoren wie Secret Manager speichern, mit der Auth-Manager-Methode können Sie jedoch den Zugriff von Agents auf API-Schlüssel an einem zentralen Ort verfolgen und verwalten. So speichern und verwenden Sie API-Schlüssel im Auth-Manager:

  1. Der Plattformadministrator richtet den Authentifizierungsanbieter ein:
    1. Erstellen Sie im Authentifizierungsmanager einen Authentifizierungsanbieter für API-Schlüssel.
    2. Generieren Sie den API-Schlüssel und speichern Sie ihn im Authentifizierungsanbieter.
    3. KI‑Agenten Zugriff auf den Authentifizierungsanbieter gewähren
  2. Ändern Sie den Agent-Code, um die Authentifizierung über den Authentifizierungsanbieter zu ermöglichen.

Weitere Informationen finden Sie unter Mit API-Schlüssel und Auth Manager authentifizieren.

Authentifizierung von Agent zu Agent

In diesem Abschnitt wird ein erweiterter Authentifizierungsablauf beschrieben. Sie sollten sich bereits mit den folgenden Themen vertraut gemacht haben:

  • JSON Web Tokens (JWTs): ID-Tokens für die Identität von Kundenservicemitarbeitern sind signierte JWTs.
  • JOSE-Header (JSON Object Signing and Encryption): ID-Tokens haben einen JOSE-Header, der den Algorithmus und den Signaturschlüssel für das ID-Token beschreibt.
  • JSON-Webschlüssel (JWKs): JWKs werden zum Signieren von ID-Tokens verwendet. Die öffentlichen JWKs für einen Agent-Identitätspool werden als JSON Web Key Set (JWKS) veröffentlicht. Mit diesen öffentlichen Schlüsseln können Sie eingehende ID-Tokens von anderen Agents validieren.

In Multi-Agenten-Architekturen arbeiten Agents häufig zusammen, indem sie Peer-Agents oder Downstream-Dienste direkt aufrufen. Sie können die Kommunikation zwischen Agent-Arbeitslasten direkt herstellen, indem Sie ein Agent-Identitäts-Identitätstoken verwenden. Das ist ein signiertes JWT, das Sie vom GKE-Metadatenserver abrufen können. So authentifizieren Anwendungsentwickler eine Verbindung zwischen Agent-Diensten:

  1. Rufen Sie ein ID-Token für die Agent-Identität vom GKE-Metadatenserver für den aufrufenden Agent ab. In diesem ID-Token muss die aud-Anforderung auf den Endpunkt des empfangenden Agenten festgelegt sein.
  2. Fügen Sie das ID-Token in den Authorization: Bearer-Anfrageheader der HTTP-Anfrage ein.
  3. Validieren Sie im empfangenden Agent das eingehende ID-Token mithilfe der öffentlichen JWKs für den Agent-Identitätspool und der verschiedenen Header- und Body-Parameter im ID-Token.

Weitere Informationen zum Anfordern, Verwenden und Validieren von ID-Tokens in Ihrem Anwendungscode finden Sie unter Bei anderen Agents authentifizieren.

Für die Agent-zu-Agent-Authentifizierung ist keine zusätzliche Google CloudKonfiguration durch einen Plattformadministrator erforderlich, da bei diesem Workflow IAM-Autorisierungsprüfungen umgangen werden. Stattdessen kommunizieren die KI-Agents direkt miteinander und autorisieren Aktionen basierend auf den Identitäten der KI-Agents.

Zugriff auf Google Cloud Ressourcen für KI-Agenten steuern

Sicherheitsadministratoren können mithilfe von IAM-Richtlinien, die auf die Hauptkonto-ID des Agents verweisen, steuern, auf welche Ressourcen ein Agent zugreifen kann. Wenn Sie den Zugriff auf Ressourcen für einen Agenten steuern möchten, der in GKE ausgeführt wird und eine Agentenidentität hat, fügen Sie Ihrer IAM-Richtlinie eine der folgenden Prinzipal-IDs hinzu:

  • Alle Agenten in einer bestimmten Vertrauensdomäne:

    principalSet://TRUST_DOMAIN/*

    In dieser Kennung ist TRUST_DOMAIN die Vertrauensdomäne für Ihre Ressourcenhierarchie. Sie hängt davon ab, ob sich der Agent in einem Projekt befindet, das zu einer Organisation gehört:

    • Projekte in einer Organisation: agents.global.org-ORGANIZATION_ID.system.id.goog, wobei ORGANIZATION_ID die ID der Organisation ist.
    • Projekte, die sich nicht in einer Organisation befinden: agents.global.proj-PROJECT_NUMBER.system.id.goog, wobei PROJECT_NUMBER die Projektnummer des Clusterprojekts ist.

  • Ein einzelner Agent in einer Vertrauensdomäne:

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

    In dieser Kennung werden die folgenden Parameter verwendet, um den jeweiligen Agent zu identifizieren:

    • PROJECT_NUMBER: Die Projektnummer des Projekts des Clusters.
    • CONTROL_PLANE_LOCATION: Die Region oder Zone der Cluster-Steuerungsebene.
    • CLUSTER_NAME: Der Name des Clusters, in dem sich der Agent befindet.
    • NAMESPACE_NAME: Der Name des Kubernetes-Namespace, in dem sich der Agent befindet.
    • SERVICEACCOUNT_NAME: der Name des Kubernetes-Dienstkontos, das von der Agent-Arbeitslast verwendet wird.

Weitere Informationen dazu, wie Sie Prinzipal-IDs für GKE-Agents finden und den Zugriff verwalten, finden Sie unter Zugriff auf Google Cloud APIs für Agents verwalten.

Die Agent-Identität unterstützt alle IAM-Richtlinientypen, z. B. Zulassungsrichtlinien, Ablehnungsrichtlinien und PAB-Richtlinien (Principal Access Boundary). Wenn Sie den Zugriff für einen Agenten in einem GKE-Cluster verwalten möchten, der die Agentenidentität verwendet, fügen Sie die Prinzipal-ID des Agenten in den entsprechenden Richtlinientyp ein. Weitere Informationen zum Konfigurieren der einzelnen IAM-Richtlinientypen finden Sie in den folgenden Themen:

KI-Agenten in Google Cloudansehen und verwalten

Wenn Anwendungsentwickler ihre Agenten in der Agent Registry registrieren, können Sie die GKE-Agenten zusammen mit den anderen Agenten sehen, die Sie in Google Cloudausführen. In der Agent Registry werden die SPIFFE-Identität des Agents, der Ort, an dem der Agent ausgeführt wird, und alle zusätzlichen Informationen zum Agent angezeigt. Für alle API-Anfragen, die mit Agent Identity authentifiziert werden, werden Audit-Logs für die Agent Registry generiert. Je nach Authentifizierungsablauf, den der Agent verwendet, enthalten Cloud-Audit-Logs die folgenden Informationen:

  • Authentifizierung mit der eigenen Identität des KI-Agenten: Die generierten Audit-Logs enthalten die Prinzipal-ID des KI-Agenten, mit der Sie den Cluster, den Namespace und das Dienstkonto des KI-Agenten finden können.
  • Delegierte Vorgänge im Namen von Endnutzern: Die generierten Audit-Logs enthalten Informationen zum Endnutzer, der die Aktion autorisiert hat, und zur SPIFFE-ID des Agents, der den Aufruf ausgeführt hat. Anhand dieser Identitätszuordnung in den Audit-Logs können Sie überprüfen, ob der Endnutzer bestimmte Aktionen autorisiert hat.

Zusätzlich zu Cloud-Audit-Logs können Anwendungsentwickler ihre Agent-Arbeitslasten so konfigurieren, dass Traces, Logs und Messwerte ausgegeben werden, die in Google Cloud Observability sichtbar sind. Weitere Informationen zum Konfigurieren der Arbeitslasten finden Sie in den folgenden Dokumenten:

Sicherheit für GKE-Agents verbessern

Sicherheitsadministratoren können agentspezifische Sicherheitsmaßnahmen separat von Einschränkungen für andere Arten von Arbeitslasten verwalten, indem sie auf die Agent-Identitäten verweisen. Berücksichtigen Sie die folgenden Schutzmaßnahmen, wenn Sie Agents ausführen:

  • Um die Auswirkungen eines kompromittierten Agents zu begrenzen, konfigurieren Sie eine Principal Access Boundary-Richtlinie (PAB-Richtlinie) für Agent-Identitäten.
  • Um die Sicherheit der Auth-Manager-Authentifizierungsanbieter zu verbessern, konfigurieren Sie Organisationsrichtlinien für Agent-Identitäten.
  • Um die Agentenverwaltung zu zentralisieren und Agentenaktionen für alle Ressourcen zu verfolgen, erzwingen Sie die Registrierung in der Agent Registry mithilfe von Annotationen und Labels mit Zugangscontrollern wie ValidatingAdmissionPolicies und MutatingAdmissionPolicies.
  • Verwenden Sie die folgenden Optionen, um die Sicherheit für direkten Agent-zu-Agent-Traffic zu verwalten:

Beschränkungen

  • Sie können nur Bereitstellungen automatisch in der Agent Registry registrieren. Andere Workload-Controller und statische Pods unterstützen keine automatische Registrierung.
  • Für Zugriffstokens für gebundene Agentenidentitäten wird nur der OAuth-Bereich https://www.googleapis.com/auth/cloud-platform verwendet. Sie können keinen anderen Bereich für die gebundenen Zugriffstokens angeben.
  • Das automatische Abrufen von gebundenen Zugriffs- oder ID-Tokens wird nur in Python-Anwendungen unterstützt, die Version 2.61.0 oder höher der google-auth-Bibliothek verwenden. Wenn Sie die Cloud-Clientbibliotheken für Python verwenden, müssen Sie eine Version verwenden, die Version 2.61.0 oder höher der google-auth-Bibliothek enthält.
  • Bestimmte Cloud-Clientbibliotheken leiten Ihre Anfragen möglicherweise nicht automatisch an mTLS-Endpunkte weiter.
  • Für die Authentifizierung zwischen Agents können Sie gebundene ID-Tokens nur für die Authentifizierung zwischen Agents verwenden, die sich in derselben Vertrauensdomäne für Agent-Identitäten befinden.

Nächste Schritte