Private Networking-Muster mit mehreren Agents in Google Cloud

Last reviewed 2026-11-09 UTC

In diesem Dokument finden Sie eine Anleitung zum Entwerfen einer privaten Netzwerkinfrastruktur, die eine öffentlich zugängliche Gemini Enterprise-Anwendung mit mehreren Agenten und privaten Verbindungen zwischen Agenten, Sub-Agenten und Tools unterstützt. Das Netzwerkdesign bietet private Verbindungen für KI-Agenten, die in der Agent Runtime auf der Gemini Enterprise Agent Platform, in Cloud Run, in der Google Kubernetes Engine (GKE), in lokalen Rechenzentren oder in anderen Clouds gehostet werden. Das Design unterstützt auch die Verbindung zu Agents, die an Internetstandorten ausgeführt werden.

Multi-Agenten-KI-Systeme umfassen häufig sensible oder proprietäre Daten der Organisation. Mit privaten Netzwerken können Sie verhindern, dass dieser Traffic über das öffentliche Internet zugänglich ist. Dieses Design verwendet die Netzwerkinfrastruktur von Google Cloud , VPC-Netzwerkressourcen (Virtual Private Cloud) und private Konnektivität zu lokalen Umgebungen oder cloudübergreifenden Netzwerken.

In dem in diesem Dokument beschriebenen Design kommunizieren Agenten mit anderen Agenten und mit Tools über das Agent2Agent-Protokoll (A2A) und das Model Context Protocol (MCP). Die Kommunikation wird privat, indem sie über ein VPC-Netzwerk weitergeleitet wird. Um Traffic in das VPC-Netzwerk und aus dem VPC-Netzwerk zu verschieben, wird in diesem Design eine Kombination aus Private Service Connect-Endpunkten, Private Service Connect-Schnittstellen und ausgehendem Direct VPC-Traffic von Cloud Run verwendet. Die Cloud Next Generation Firewall (Cloud NGFW) steuert den Traffic, der das VPC-Netzwerk passiert. Zusätzliche Sicherheitsebenen ermöglichen einen kontrollierten ausgehenden Internet-Traffic über Secure Web Proxy und API-Dienstzugriffsrichtlinien über einen VPC Service Controls-Perimeter.

Dieses Dokument richtet sich an Architekten, Entwickler und Administratoren, die Cloud AI-Infrastrukturen und ‑Anwendungen erstellen und verwalten. In diesem Dokument wird davon ausgegangen, dass Sie ein grundlegendes Verständnis von KI-Agenten und ‑Modellen haben und mit Netzwerkkonzepten von Google Cloud vertraut sind.

Multi-Agenten-Designmuster

Für eine Gemini Enterprise-App mit mehreren Agenten ist ein benutzerdefinierter Agent erforderlich, der als Orchestrator oder Root-Agent für Verbindungen zu Tools und Sub-Agenten dient. Um private Verbindungen zu Tools und Sub-Agents zu implementieren, die inGoogle Cloud oder lokal gehostet werden, wird ein VPC-Netzwerk mit privaten IP-Adressen verwendet. Der Root-Agent wird in der Infrastruktur von Google gehostet und verwendet die Agent Runtime, Cloud Run oder GKE. Das Multi-Agenten-Designmuster hebt diese Interaktionen hervor:

  1. Gemini Enterprise-App, die mit benutzerdefinierten Root-Agenten interagiert Gemini Enterprise-Apps bieten eine verwaltete Benutzeroberfläche mit integrierten Sicherheitsfunktionen, die die Funktionen benutzerdefinierter KI-Agenten verfügbar machen. Benutzerdefinierte Root-Agenten werden bei Gemini Enterprise registriert und in Apps für Endnutzer verfügbar gemacht. Der benutzerdefinierte Root-Agent fungiert als übergeordneter Workflow-Orchestrator und delegiert spezialisierte Aufgaben an Sub-Agenten. In dieser Architektur werden benutzerdefinierte Root-Agenten verwendet, die in der Agent Runtime, in Cloud Run oder in der GKE gehostet werden.
  2. Root-Agenten, die mit Sub-Agenten und Tools interagieren. Der Kern des KI-System-Workflows und der Geschäftslogik befindet sich im Root-Agenten und in spezialisierten Sub-Agenten. Die Flexibilität des Agenten-Frameworks, der Laufzeit und der Hosting-Plattform ermöglicht verschiedene Optionen, um Root-Agenten über das VPC-Netzwerk mit Sub-Agenten und Tools zu verbinden. Wenn Sie für diesen Teil der Architektur VPC-Netzwerke verwenden, können Agenten von Ihnen definierte private Netzwerkpfade nutzen, die andere private Endpunkte, Sicherheitskontrollen für Unternehmen und eine größere Netzwerkreichweite bereitstellen.

Allgemeine Übersicht über eine Multi-Agenten-Netzwerkarchitektur.

Die Architektur umfasst die folgenden Komponenten:

  • Gemini Enterprise-Anwendung: Das Frontend, über das Nutzer auf eine In-App-Chat-Oberfläche zugreifen und mit dem Multi-Agenten-KI-System interagieren können. Nutzer können über das öffentliche Internet oder privat über Hybridverbindungen auf Gemini Enterprise-Apps zugreifen.
  • Benutzerdefinierte KI-Agenten: Root-Agenten, die mit Gemini Enterprise erstellt und registriert wurden und in Agent Runtime, Cloud Run oder GKE gehostet werden. Diese Root-Agenten fungieren als Orchestratoren, die Aufgaben an Sub-Agenten delegieren.
  • VPC-Netzwerk: Eine Ressource, die Sie steuern, um Agenten IP-Netzwerkverbindungen zu privaten Endpunkten und eine umfassendere Netzwerkerreichbarkeit zu ermöglichen. Das VPC-Netzwerk bietet eine Plattform zum Implementieren von privater Konnektivität und Netzwerksicherheitskontrollen für Agent-Anfragen an andere Agenten und Tools.
  • Sub-Agenten: Spezialisierte Agenten, die durch den Workflow des Root-Agenten ausgelöst werden. Sub-Agenten kommunizieren über das A2A-Protokoll, das die Interoperabilität zwischen Agenten unabhängig von Programmiersprache und Laufzeit ermöglicht.
  • Tools: Remote-Systeme, die Dienste wie APIs, Datenquellen und Workflow-Funktionen bereitstellen. Diese Tools rufen Daten ab und führen Aktionen oder Transaktionen für Agenten aus. Tools sind extern und Agenten verbinden sich mit ihnen und interagieren mit ihnen über die MCP-Spezifikation.

Dieses allgemeine Multi-Agenten-Designmuster zeigt die Netzwerkkomponenten, die in einem agentischen KI-System enthalten sind. Es unterstützt viele verschiedene Arten von Routingmustern zwischen Agenten. Informationen zu anderen Designmustern für KI-Systeme finden Sie unter Designmuster für Ihr agentisches KI-System wählen.

Gemeinsam genutzte VPC

Das Multi-Agent-Designmuster verwendet eine freigegebene VPC, um die Netzwerk- und Sicherheitsbefugnisse und -verantwortlichkeiten zu zentralisieren. Dieses Design bietet Entwicklern Umgebungen, die die Sicherheitsanforderungen einer Organisation erfüllen. Wir empfehlen, eine freigegebene VPC zu verwenden, um Ihre Netzwerk- und Sicherheitskonfigurationen zu zentralisieren und zu vereinfachen.

In einer gemeinsam genutzten VPC-Architektur enthält ein Hostprojekt die gemeinsam genutzten Netzwerkressourcen, einschließlich VPC-Netzwerken, Cloud Routern, Subnetzen, Firewalls und Cloud DNS. Administratoren können Dienstprojekten Zugriff auf diese Ressourcen gewähren. Dienstprojekte enthalten die Agent Runtime-Ressourcen, einschließlich Agent Runtime, Cloud Run, GKE, Gemini Enterprise und anwendungsspezifischer Load Balancer.

Eine freigegebene VPC erzwingt eine klare Grenze zwischen Netzwerk- und Sicherheitsadministratoren und KI-App-Entwicklern:

  • Netzwerk- und Sicherheitsadministratoren steuern die Kerninfrastruktur, z. B. VPC-Routing, Subnetze, DNS-Peering und Firewallrichtlinien.
  • KI-App-Entwickler erstellen Agenten in angehängten Dienstprojekten, ohne Berechtigungen zum Ändern der zugrunde liegenden Netzwerkinfrastruktur zu haben.

Wenn Sie Netzwerk- und Sicherheitsbereitstellungen in einem Hostprojekt zentralisieren, erstellen Sie einen zentralen Verwaltungspunkt für die Kommunikation zwischen Agenten und zwischen Agenten und Diensten. Dieses Design vereinfacht die Durchsetzung von Sicherheitsrichtlinien für viele verschiedene Dienstprojekte und sorgt gleichzeitig für eine konsistente Verbindung.

Sie können Ihr freigegebene VPC-Netzwerk in ein Cross-Cloud Network einbinden, indem Sie Network Connectivity Center (NCC)-VPC-Spokes verwenden, um das freigegebene VPC-Netzwerk als Arbeitslast-VPC-Netzwerk hinzuzufügen. Diese Implementierung bietet der freigegebene VPC vollständige Erreichbarkeit von NCC-Hub-Routen und Konnektivität zu Dienstzugriffspunkten von anderen Spokes.

Anfragen, die von benutzerdefinierten Root-Agenten initiiert werden, verwenden ein privates, vom Kunden verwaltetes VPC-Netzwerk, um sichere Netzwerkpfade zu Sub-Agenten, Tools und Diensten bereitzustellen. Das VPC-Netzwerkrouting steuert die Erreichbarkeit privater Endpunkte. Cloud NGFW-Richtlinien, die auf das VPC-Netzwerk angewendet werden, regeln den Netzwerkzugriff.

Agents erhalten sicheren Zugriff auf private VPC-Netzwerkpfade, einschließlich Verbindungen zu Folgendem:

  • Andere VPC-Netzwerke über VPC-Netzwerk-Peering, Multi-NIC-Appliances oder NCC.
  • Private Service Connect-Endpunkte für den Zugriff auf Erstellerdienste.
  • Verwaltete Dienste mit privaten IP-Adressen, z. B. Cloud SQL.
  • Frontends des internen Load Balancers und Compute Engine-Ressourcen.
  • Google APIs über den privater Google-Zugriff oder über Private Service Connect.
  • Das Internet, gesteuert über Secure Web Proxy.
  • Hybrid- und cloudübergreifende Ziele mit Cloud Interconnect, Cloud VPN, Router-Appliance oder SD-WAN.
  • Jedes Endpunktziel, das über das IP-Routing des VPC-Netzwerk erreichbar ist.
  • Andere KI-Agenten, Tools und unterstützende Dienste.

Weitere Informationen zu freigegebene VPC finden Sie in den folgenden Ressourcen:

Gemini Enterprise-Netzwerk

Gemini Enterprise Apps sind verwaltete Ressourcen, die in einer gehosteten Umgebung außerhalb des VPC-Netzwerk, aber innerhalb des Google-Netzwerks ausgeführt werden. In den folgenden Abschnitten wird die Konfiguration für die Netzwerkverbindung zwischen dem Nutzer und der Gemini Enterprise-App sowie zwischen der App und den Agenten beschrieben.

Nutzerchat mit Gemini Enterprise-Apps

Nutzer chatten mit der Gemini Enterprise-App über eine browserbasierte App, die Anfragen an Google APIs und Google-Dienste sendet. Wenn Sie die private Nutzerkonnektivität aktivieren möchten, können Sie die Google API-URLs so konfigurieren, dass sie in private IP-Adressbereiche aufgelöst werden, die über Ihr VPC-Netzwerk weitergeleitet werden. Weitere Informationen finden Sie unter Privaten UI-Zugriff konfigurieren.

Gemini Enterprise-Anwendungen für benutzerdefinierte Agenten

Sie registrieren benutzerdefinierte Agenten beim Gemini Enterprise-Erkennungsdienst. Wenn Sie einen Agenten registrieren, ordnet Gemini Enterprise den Namen des Agenten einem bestimmten Ziel zu, entweder dem Ressourcen-URI der Agent Runtime oder der URL des A2A-Agenten. Gemini Enterprise-Apps haben eine integrierte Chat-Oberfläche, die als Assistent bezeichnet wird. Wenn ein Nutzer einen Agenten mit @agent_name angibt oder der Assistent beschließt, die Anfrage zu delegieren, sucht die Anwendung den Agenten in der Registry, um den zugehörigen Endpunkt zu finden.

Wenn Sie einen Stamm-Agenten bei Gemini Enterprise registrieren, können Sie ihn überall als benutzerdefinierten Agenten bereitstellen. Benutzerdefinierte Agenten in Agent Runtime und Cloud Run können vorhandene private Netzwerkpfade verwenden, ohne zusätzliche Netzwerkressourcen konfigurieren zu müssen. Wenn Sie einen benutzerdefinierten Agent in GKE bereitstellen möchten, müssen Sie den Dienst mit einem externen Gateway verfügbar machen. Informationen zum Konfigurieren des externen Gateways für mehr Sicherheit finden Sie weiter unten in diesem Dokument unter GKE-Netzwerk.

Für Anfragen an benutzerdefinierte Agenten verwendet Gemini Enterprise die Identität des Discovery Engine-Dienstkontos der Gemini Enterprise Agent Platform. Der Netzwerkpfad und die Autorisierungsmechanismen unterscheiden sich je nach verwendeter Hostingplattform:

  • Benutzerdefinierte KI-Agenten in Agent Runtime: Der Dienst-Agent der Agent Platform Discovery Engine enthält die erforderlichen IAM-Rollen (Identity and Access Management) der Agent Platform, um Agent Runtime-Ressourcen als integrierte Funktion aufzurufen. Das System leitet Anfragen an den Agent Platform API-Dienst über das Google-Netzwerk als internen API-Aufruf weiter.
  • Benutzerdefinierte Agenten in Cloud Run: Gemini Enterprise-Apps verwenden die Dienst-Agent-Identität der Agent Platform Discovery Engine, um Aufrufe an die Standard-.run.app-URL zu senden, die über die Agentenkarte registriert ist. Dabei wird das OIDC-ID-Token des Dienst-Agenten im X-Serverless-Authorization-Authentifizierungsheader angehängt. Damit der Cloud Run-Dienst des KI-Agenten diese Aufrufe autorisieren kann, müssen Sie dem Discovery Engine-Dienst-Agenten die IAM-Rolle „Cloud Run Invoker“ (roles/run.invoker) zuweisen. Anfragen an Cloud Run werden über das Google-Produktionsnetzwerk an den Ingress des Google Front End (GFE) für Cloud Run weitergeleitet.

  • Benutzerdefinierte Agenten in GKE: Gemini Enterprise-Apps verwenden die Dienstagentenidentität der Agent Platform Discovery Engine, um Aufrufe an die URL zu senden, die auf der Agentenkarte registriert ist. Das öffentliche DNS muss den Hostnamen in eine externe IP-Adresse auflösen können, die vom Gateway verwaltet wird. Wir empfehlen, den Load Balancer gke-l7-regional-external-managed oder den Load Balancer gke-l7-global-external-managed zu verwenden. Für zusätzliche Sicherheit empfehlen wir, dass Gemini Enterprise einen in GKE gehosteten A2A-Agenten über Identity-Aware Proxy (IAP) aufruft. Damit IAP diese Aufrufe autorisieren kann, müssen Sie dem Discovery Engine-Dienst-Agenten die IAM-Rolle „Nutzer von IAP-gesicherten Web-Apps“ (roles/iap.httpsResourceAccessor) zuweisen. Das Google-Produktionsnetzwerk leitet Anfragen an GKE an das GFE für den externen Application Load Balancer-Ingress weiter.

    Informationen zum Sichern von GKE Ingress vor Gemini Enterprise finden Sie in den Abschnitten IAP und Google Cloud Armor weiter unten in diesem Dokument.

Private Netzwerke für Agent-Hosting-Plattformen

Nachdem ein Nutzer eine Anfrage an die Gemini Enterprise App gestellt hat, werden Anfragen von benutzerdefinierten Root-Agenten an Sub-Agenten und Tools gesendet. Die Hostingplattformen für benutzerdefinierte Agenten stellen die Schnittstelle zwischen Gemini Enterprise und Ihren VPC-Netzwerken bereit. Die Hostingplattformen für Ihre containerisierten Agenten und Tools sind Agent Runtime, Cloud Run und GKE.

Bei der Auswahl einer Hosting-Plattform für KI-Agenten müssen Sie die privaten Netzwerkmuster, Sicherheitskontrollen, Verwaltungsoptionen, den Anpassungsgrad und die Sicherheits-Compliance der einzelnen Plattformen berücksichtigen. Weitere Informationen zur Auswahl einer Hosting-Plattform für KI-Agenten finden Sie unter Modelle und Infrastruktur für Ihre generative KI-Anwendung auswählen und Architekturkomponenten für agentische KI auswählen.

Sie stellen eine private VPC-Verbindung über verschiedene Mechanismen her, je nachdem, welche Agent-Hosting-Plattform Sie verwenden:

  • Benutzerdefinierte KI-Agenten in Agent Runtime: Private Service Connect-Schnittstellen verbinden die Agent Runtime-Laufzeiten mit dem VPC-Netzwerk. Sie erstellen einen Netzwerkanhang in einem Subnetz Ihres VPC-Netzwerk und erteilen Agent Runtime die Berechtigung, sich daran anzuhängen. Traffic, der von Agent Runtime gesendet wird, wird im VPC-Netzwerk so angezeigt, als ob er von der Subnetz-IP-Adresse des Anhangs stammt. Das VPC-Netzwerk leitet den Traffic dann an die entsprechende Ziel-IP-Adresse weiter.
  • Benutzerdefinierte Agenten in Cloud Run: Der ausgehende Direct VPC-Traffic von Cloud Run verbindet die Cloud Run-Dienstinstanzen mit dem VPC-Netzwerk. Das VPC-Netzwerk, das bei der Bereitstellung eines Cloud Run-Dienstes angegeben wird, kann aus dem Cloud Run-Dienstprojekt oder aus dem freigegebene VPC-Hostprojekt stammen. Traffic, der von Cloud Run gesendet wird, wird im VPC-Netzwerk so angezeigt, als ob er von der Subnetz-IP-Adresse des ausgehenden Direct VPC-Traffics stammt. Das VPC-Netzwerk leitet den Traffic dann an die entsprechende Ziel-IP-Adresse weiter.
  • Benutzerdefinierte Agents in GKE: GKE-Cluster befinden sich direkt im VPC-Netzwerk und verwenden lokale Subnetz-IP-Adressen. Standardmäßig wird für ausgehenden GKE-Traffic die Pod-IP-Adresse als Quell-IP-Adresse verwendet. Wenn Sie die Maskierung konfigurieren, wird für ausgehenden GKE-Traffic die Knoten-IP-Adresse als Quell-IP-Adresse verwendet. Der gesamte ausgehende GKE-Traffic wird über das VPC-Netzwerk weitergeleitet.

Die folgenden Abschnitte enthalten zusätzliche Informationen zum Verwalten von Anfragen für eingehenden und ausgehenden Traffic in das und aus dem VPC-Netzwerk für die einzelnen Agent-Hosting-Plattformen. Die Netzwerkaspekte gelten sowohl für die Funktionen des Stamm-KI-Agenten als auch für die des Sub-Agenten.

Agent Runtime-Netzwerk

In diesem Abschnitt wird das private Netzwerk für Root-Agenten und Sub-Agenten beschrieben, die in der Agent Runtime gehostet werden. Wenn Sie die Agent Runtime zum Hosten Ihres Root-Agenten verwenden, müssen Sie Gemini Enterprise und die Agent Runtime im selben Projekt bereitstellen.

Agent Runtime hostet Container in der Google-Infrastruktur außerhalb Ihres VPC-Netzwerk. Wenn Sie die private Konnektivität zu anderen Agenten aktivieren möchten, können Sie Ihren Agenten mit den folgenden Methoden mit Ihrem VPC-Netzwerk verbinden:

Wenn Sie Anfragen zwischen Ihren Agenten und anderen Agenten zulassen möchten, richten Sie beide der oben genannten Verbindungen ein.

Ausgehender Traffic von der Agent Runtime zum VPC-Netzwerk

Die Agent Runtime verwendet ein von Google verwaltetes Mandantenprojekt für ausgehenden Netzwerktraffic. Das Mandantennetzwerk bietet Agenten Konnektivität zu Google APIs und ausgehenden Internet-Traffic, ist aber standardmäßig nicht direkt mit VPC-Netzwerken von Kunden verbunden.

Um Agenten mit Ressourcen in Ihrem VPC-Netzwerk zu verbinden, verwendet die Agent Runtime Private Service Connect-Schnittstellen. Agent Runtime stellt im Mandantenprojekt eine Netzwerkschnittstelle bereit, die eine Verbindung zu einer Netzwerkanhangsressource in Ihrem Projekt herstellt. Über diese Verbindung wird ein sicherer Datenpfad zwischen der Agent Runtime-Laufzeit und dem VPC-Netzwerk erstellt. Wenn Sie eine Private Service Connect-Schnittstelle in Ihrem Agent Runtime-Projekt konfigurieren, leitet das System den gesamten Agent-Traffic, der nicht für Google APIs bestimmt ist, an das VPC-Netzwerk weiter.

Informationen zum Bereitstellen des ausgehenden Traffics für das Agent Runtime-VPC-Netzwerk finden Sie in den folgenden Ressourcen:

Weitere Informationen zum Sichern von Agenten und des VPC-Netzwerk für ausgehenden Traffic der Agent Runtime finden Sie in den folgenden Abschnitten dieses Dokuments:

Eingehender Agent Runtime-Traffic aus dem VPC-Netzwerk

Anfragen an Agenten, die in der Agent Runtime ausgeführt werden, werden über den Agent Platform API-Endpunkt (aiplatform.googleapis.com) gestellt. Wenn Sie Google API-Endpunkte über private Netzwerkpfade aus dem VPC-Netzwerk erreichen möchten, verwenden Sie den privater Google-Zugriff oder Private Service Connect-Endpunkte für Google APIs.

Private Nutzer, die Anfragen an Agenten senden, müssen den Hostnamen des Agent Platform API-Endpunkt in den privaten IP-Adressbereich für den privaten Google-Zugriff oder in die IP-Adresse des Private Service Connect-Endpunkts für Google APIs auflösen. Eine private verwaltete Cloud DNS-Zone für googleapis.com löst Anfragen für die Agent Platform API auf. Das VPC-Netzwerk leitet die Anfrage direkt über das Google-Produktionsnetzwerk weiter.

Wenn Sie den privater Google-Zugriff oder Private Service Connect für Google APIs verwenden, können Sie den Traffic von Ihrem VPC-Netzwerk zu Agent Runtime mit den folgenden Produkten und Funktionen schützen:

Zusätzliche Überlegungen zum Agent Runtime-Netzwerk

Ausgehender Traffic von Agent Runtime, der Private Service Connect-Schnittstellen verwendet, kann nur an RFC 1918-IP-Adressbereiche im VPC-Netzwerk weitergeleitet werden. Informationen zu bestimmten Zielbereichen, die nicht über ausgehenden Traffic von Agent Runtime weitergeleitet werden können, finden Sie unter Anforderungen an Subnetz-IP-Bereiche. Wenn Sie Ziele mit nicht routingfähigen IP-Adressbereichen erreichen möchten, verwenden Sie eine explizite Proxykonfiguration auf den Agents und stellen Sie Proxyressourcen bereit, die eine routingfähige IP-Adresse im VPC-Netzwerk verwenden.

Wenn Agent Runtime ohne Private Service Connect-Schnittstelle bereitgestellt wird, hat es standardmäßig Zugriff auf das Internet. Zum Schutz vor Daten-Exfiltration können Sie den Standardzugriff deaktivieren, indem Sie VPC Service Controls aktivieren.

Wenn Agent Runtime mit einer Private Service Connect-Schnittstelle bereitgestellt wird, ist der direkte ausgehende Internet-Traffic unabhängig von VPC Service Controls deaktiviert. Wenn Ihr Agent auf ein Ziel zugreifen muss, das die Agent Runtime normalerweise nicht erreichen kann, z. B. das Internet, gehen Sie so vor:

  1. Konfigurieren Sie Secure Web Proxy in einem RFC 1918-Subnetz Ihres VPC-Netzwerk. Sie müssen den Proxy im expliziten Proxy-Routing-Modus konfigurieren.
  2. Erstellen Sie einen Cloud DNS-Eintrag für den Hostnamen des Secure Web Proxy.
  3. Konfigurieren Sie DNS-Peering für Agent Runtime, um die Auflösung von DNS-Abfragen des Agents an die private Adresse des Secure Web Proxy im VPC-Netzwerk zu unterstützen.
  4. Gehen Sie beim Bereitstellen von Agenten so vor:
    1. Definieren Sie Umgebungsvariablen, um den expliziten Proxy zu verwenden, indem Sie den Hostnamen und den Port des Secure Web Proxy angeben.
    2. Wenn Sie auf ein privates Ziel zugreifen, konfigurieren Sie eine private DNS-Zone für dieses Ziel.

Nachdem der ausgehende Traffic von Agent Runtime das VPC-Netzwerk erreicht hat, kann er jedes Netzwerkziel erreichen, das über das VPC-Netzwerk routingfähig ist. Informationen dazu, wie Sie den Umfang der ausgehenden Netzwerkziele einschränken, die für Agent Runtime-Agenten verfügbar sind, finden Sie im Abschnitt Cloud NGFW weiter unten in diesem Dokument.

Cloud Run-Netzwerk

In diesem Abschnitt wird das private Netzwerk für Root-Agenten und Sub-Agenten beschrieben, die in Cloud Run gehostet werden. Cloud Run hostet Container in der Google-Infrastruktur außerhalb Ihres VPC-Netzwerk. Wenn Sie die private Konnektivität zu anderen Agents aktivieren möchten, können Sie Ihren Agent mit den folgenden Methoden mit Ihrem VPC-Netzwerk verbinden:

Wenn Sie Anfragen zwischen Ihren Agenten und anderen Agenten zulassen möchten, richten Sie beide der oben genannten Verbindungen ein.

Ausgehender Cloud Run-Traffic zum VPC-Netzwerk

Wenn Sie Cloud Run-Verbindungen zu einem VPC-Netzwerk initiieren möchten, empfehlen wir die Verwendung von ausgehendem Direct VPC-Traffic. Bei ausgehendem Direct VPC-Traffic stellen Cloud Run-Instanzen eine direkte Verbindung zum freigegebenen VPC-Netzwerk her. Dazu verwenden sie eine IP-Adresse aus dem Subnetz, das Sie beim Bereitstellen des ausgehenden Direct VPC-Traffics angeben.

Gehen Sie beim Konfigurieren von ausgehendem Direct VPC-Traffic so vor:

  1. Konfigurieren Sie das Zielsubnetz mit aktiviertem privaten Google-Zugriff.
  2. Konfigurieren Sie das Traffic-Routing so, dass der gesamte Traffic an das VPC-Netzwerk weitergeleitet wird.

Bei dieser Konfiguration wird der gesamte Traffic aus Datenschutzgründen über das VPC-Netzwerk gesendet. Anfragen von Cloud Run an andere Google APIs werden über das interne Google-Netzwerk gesendet.

Alle DNS-Abfragen von Cloud Run verwenden die Cloud DNS-Richtlinie und die Zonen, die mit dem VPC-Netzwerk verknüpft sind. Es ist keine zusätzliche DNS-Peering-Konfiguration erforderlich. In Cloud Run gehostete Agents lösen alle privaten Cloud DNS-Zonen und öffentlichen Hostnamen auf.

Informationen dazu, wie Sie Agents und das VPC-Netzwerk für ausgehenden Cloud Run-Traffic weiter schützen können, finden Sie in den folgenden Abschnitten dieses Dokuments:

Eingehender Cloud Run-Traffic aus dem VPC-Netzwerk

Cloud Run ist eine von Google verwaltete Plattform, die in einer Umgebung außerhalb des VPC-Netzwerk ausgeführt wird. In dieser Umgebung wird der stabile *.run.app-URL-Endpunkt für Cloud Run-Dienste gehostet, die KI-Agenten- oder Tool-Arbeitslasten ausführen. Diese Endpunkte werden vom selben GFE-Einstiegspunkt bereitgestellt, der auch *.googleapis.com-API-Dienste bereitstellt. Cloud Run verwendet dieselben zugrunde liegenden Netzwerkpfade, die private Konnektivität für den privater Google-Zugriff und für Private Service Connect für Google APIs ermöglichen.

Private Nutzer im VPC-Netzwerk, die Abfragen an Agents oder Tools senden, müssen den Hostnamen run.app in den privaten IP-Adressbereich für den privaten Google-Zugriff oder in die IP-Adresse des Private Service Connect-Endpunkts für Google APIs auflösen. Eine private verwaltete Cloud DNS-Zone für die run.app-URL löst Anfragen für Cloud Run-Dienste auf. Das VPC-Netzwerk leitet die Anfrage direkt über das Google-Produktionsnetzwerk weiter.

Wenn Sie den eingehenden Traffic für Cloud Run auf Intern festlegen, wird der Zugriff auf Ihren Dienst eingeschränkt, da nur Anfragen von verifizierten internen Quellen zugelassen werden. Zu den genehmigten Quellen gehören:

  • VPC-Netzwerke des Cloud Run-Dienstprojekts.
  • Das gemeinsam genutzte VPC-Netzwerk, das den Direct VPC-Endpunkt für ausgehenden Traffic hostet.
  • Ressourcen, die sich im selben VPC Service Controls-Perimeter befinden.
  • Interne Application Load Balancer im VPC-Netzwerk.
  • Google-Dienste wie Cloud Scheduler und Pub/Sub, die sich im Dienstprojekt oder VPC Service Controls-Perimeter befinden.

Wenn Sie keinen gemeinsamen VPC Service Controls-Perimeter für die aufrufenden und aufgerufenen Dienste verwenden, wird Traffic von außerhalb des Cloud Run-Dienstprojekts oder der freigegebene VPC-Umgebung als externer Traffic behandelt. Dazu gehört auch Traffic von anderen Google Cloud-Diensten wie Agent Runtime und anderen Cloud Run-Diensten. Damit die interne Prüfung des eingehenden Traffics von Cloud Run erfolgreich ist, muss dieser Traffic so weitergeleitet werden, dass er scheinbar aus dem VPC-Netzwerk des Zieldienstes stammt.

Sie haben folgende Möglichkeiten, die erforderliche interne Netzwerkattribution bereitzustellen:

  • Mit Private Service Connect-Endpunkten können Dienste in anderen VPCs oder Projekten über eine private IP-Adresse in Ihrem VPC-Netzwerk eine Verbindung zu Google APIs und Google-Diensten herstellen, einschließlich Ihres Cloud Run-Dienstes.
  • Leiten Sie Traffic über einen internen Application Load Balancer weiter, der sich in Ihrem VPC-Netzwerk vor Ihrem Cloud Run-Dienst befindet. Der Load Balancer leitet Anfragen von anderen Diensten über das VPC-Netzwerk weiter, damit sie die internen Kriterien für eingehenden Traffic erfüllen.

Interne Application Load Balancer mit Backends für serverlose Netzwerk-Endpunktgruppen (NEG) erstellen eine VPC-Ressource, die direkt einem Cloud Run-Dienst zugeordnet ist. In diesem Modell beendet der Load Balancer Client-TLS-Verbindungen mit einem vertrauenswürdigen Zertifikat. Interne Application Load Balancer unterstützen zusätzliche Sicherheitskontrollen, einschließlich Backend-Sicherheitsrichtlinien von Cloud Armor und zusätzlicher Autorisierungsrichtlinien.

Standardmäßig ist für den Zugriff auf alle Cloud Run-Dienste eine IAM-Authentifizierung erforderlich. Wir empfehlen, für jeden Dienst eine eigene Identität zu verwenden und dem Hauptkonto die IAM-Rolle „Cloud Run-Aufrufer“ (roles/run.invoker) zuzuweisen.

Informationen zum Konfigurieren der Steuerelemente für eingehenden Traffic in Cloud Run finden Sie in den folgenden Ressourcen:

Wenn Sie den privater Google-Zugriff oder Private Service Connect-Endpunkte für Google APIs verwenden, um Traffic von Ihrem VPC-Netzwerk an Cloud Run zu senden, können Sie diesen Traffic mit den folgenden Produkten und Funktionen schützen:

Wenn Sie einen internen Application Load Balancer verwenden, um Traffic von Ihrem VPC-Netzwerk an Cloud Run zu senden, können Sie diesen Traffic mit den folgenden Produkten und Features schützen:

GKE-Netzwerk

In diesem Abschnitt wird das Netzwerk für Agenten beschrieben, die auf GKE basieren.

GKE und Gemini Enterprise

Als Host für KI-Agenten und ‑Tools bietet die GKE eine hochgradig anpassbare Plattform für Netzwerk- und Sicherheitskontrollen. Ein Multi-Agenten-KI-System, das in der GKE bereitgestellt wird, kann die betriebliche Effizienz im großen Maßstab verbessern. Sie lässt sich eng in andere Kubernetes-Anwendungen und größere Mikrodienstarchitekturen einbinden.

GKE-Cluster sind Compute Engine-VM-Knoten, die in einem Subnetz des VPC-Netzwerk ausgeführt werden. Gemini Enterprise Apps sind verwaltete Ressourcen, die in einer gehosteten Umgebung außerhalb des VPC-Netzwerk ausgeführt werden. Damit Gemini Enterprise-Apps benutzerdefinierte Agenten aufrufen können, die in GKE gehostet werden, müssen Sie ein externes Gateway mit einer öffentlichen IP-Adresse und einem DNS-Namen sicher bereitstellen. Der Traffic fließt vom ausgehenden Gemini Enterprise-Traffic zum Google Edge-Netzwerk, wo er eine optimierte Route zum externen GKE-Load-Balancer nimmt.

Es ist wichtig, den GKE-Endpunkt durch starke Authentifizierung und Autorisierung, Cloud Armor und eingeschränkte Berechtigungen zu sichern. Wenn Sie ein umfassendes Defense-in-Depth-Modell zum Schutz von KI-Agenten bereitstellen möchten, die in der GKE ausgeführt werden, sollten Sie die in den folgenden Abschnitten beschriebenen Sicherheitskontrollen in Betracht ziehen.

GKE-Betriebsmodus

GKE bietet diese Betriebsmodi, um Verwaltung und Kontrolle in Einklang zu bringen:

  • Autopilot: Google automatisiert die gesamte GKE-Clusterinfrastruktur, einschließlich der Steuerungsebene, der Knotenbereitstellung, der Sicherheitshärtung und der Skalierung.
  • Standard: Google verwaltet die Steuerungsebene. Sie sind weiterhin vollständig für die Konfiguration von Knotenpools verantwortlich, z. B. für die Auswahl von Maschinentypen, die Verwaltung von Betriebssystem-Images und die manuelle Skalierung.
Härtung von Infrastruktur und Steuerungsebene
  • Private GKE-Cluster: Knoten ohne öffentliche IP-Adressen bereitstellen, damit die Laufzeitumgebung vom direkten Internetzugriff isoliert ist.
  • Autorisierte Netzwerke für die Steuerungsebene: Beschränken Sie den Administratorzugriff auf die Kubernetes API auf bestimmte, vertrauenswürdige IP-Adressbereiche. Dadurch wird die Steuerungsebene vor nicht autorisierten Konfigurationsänderungen geschützt. Sichern Sie den DNS-Endpunkt für die Kubernetes API mit IAM und VPC Service Controls von Google Cloud.
Identität und Zugriff (Zero Trust)
  • IAP: Fungiert als Gatekeeper auf Load-Balancer-Ebene. So wird sichergestellt, dass nur authentifizierte Nutzer mit den richtigen IAM-Berechtigungen auf den Agent-Endpunkt zugreifen können. Bei diesem Ansatz wird der Sicherheitsperimeter effektiv vom Netzwerk auf den einzelnen Nutzer und seinen Gerätekontext verlagert.
Edge-Schutz und Trafficverwaltung
  • Cloud Armor: Bietet robuste Edge-Sicherheit, einschließlich WAF-Regeln (Web Application Firewall) zum Blockieren schädlicher Nutzlasten, DDoS-Schutz zur Gewährleistung der Verfügbarkeit und Ratenbegrenzung, um eine Überlastung des Dienstes zu verhindern.
  • Model Armor: Model Armor wurde speziell für die LLM-Sicherheit entwickelt und prüft und bereinigt Prompts und Antworten in Echtzeit, um Prompt Injection und Daten-Exfiltration zu verhindern.
Interne Netzwerkisolation
  • Kubernetes-Netzwerkrichtlinien: Erzwingen eine detaillierte Kommunikation mit geringsten Berechtigungen zwischen Mikrodiensten. Standardmäßig wird der gesamte Traffic abgelehnt, sofern Sie ihn nicht explizit zulassen. Dadurch werden laterale Bewegungen innerhalb des Clusters verhindert.

Ausgehender GKE-Traffic zum VPC-Netzwerk

Das VPC-Netzwerk leitet ausgehende Verbindungen von Agents weiter, die in GKE gehostet werden. Der Standardnetzwerkmodus für GKE-Cluster ist VPC-nativ. Dieser Modus bietet die folgenden Attribute:

  • Der GKE-Cluster verwendet Alias-IP-Adressbereiche.
  • Pod-IP-Adressen werden durch Angabe des Pod-IP-Bereichs reserviert.
  • Pod-IP-Adressen sind nativ routingfähig im VPC-Netzwerk des Clusters und in anderen verbundenen VPC-Netzwerken.

Wenn ein Agent-Pod mit einem Subagent-Pod auf demselben Knoten kommuniziert, wird der Traffic lokal innerhalb des Netzwerk-Namespace des Knotens weitergeleitet. Wenn sich der Ziel-Agent-Pod auf einem anderen Knoten im Cluster befindet, wird der Traffic über die VPC-Netzwerkroutingtabelle weitergeleitet. Damit ein Agent-Pod mit anderen VPC-Ressourcen wie Load Balancern oder Private Service Connect-Endpunkten kommunizieren kann, kann er das Ziel über dasselbe Standard-VPC-Routing erreichen, vorbehaltlich der Firewallregeln.

Mit den folgenden Produkten und Diensten können Sie Traffic schützen, der Ihren GKE-Cluster verlässt:

Eingehender GKE-Traffic aus dem VPC-Netzwerk

Kubernetes-Dienste bieten Zugriff auf GKE-Ressourcen. Für ein Multi-Agenten-KI-System empfehlen wir die Verwendung eines GKE-Gateways oder eines GKE-Inferenz-Gateways. Das Gateway bietet erweiterte Funktionen mit Traffic-Steuerung, operativer Trennung von Ressourcen und Sicherheitsintegrationen. Je nach Systemanforderungen sind jedoch auch andere Optionen für eingehenden Traffic verfügbar.

Die Gateway-Ressource erstellt einen Application Load Balancer und stellt alle erforderlichen Load-Balancing-Komponenten bereit. Die Backend-Netzwerk-Endpunktgruppen des Dienstes sind so konfiguriert, dass Load Balancing direkt für Container bereitgestellt wird. Wenn Sie einen Dienst intern für Traffic aus dem VPC-Netzwerk bereitstellen möchten, verwenden Sie die Gateway-Klassen für regionale interne Application Load Balancer (gke-l7-rilb) oder regionenübergreifende interne Application Load Balancer (gke-l7-cross-regional-internal-managed-mc).

Application Load Balancer bieten zusätzliche Sicherheitskontrollpunkte zum Schutz von KI-Agenten und ‑Tools, die auf GKE-Clustern gehostet werden:

  • Cloud Armor: Schützt Dienste, indem eine Cloud Armor-Sicherheitsrichtlinie an die Backend-Dienste angehängt wird, die vom Gateway verwaltet werden. Sie bietet WAF-Prüfung, IP-Adress- und standortbasierte Filterung, DDoS-Schutz und Ratenbegrenzung, bevor der Traffic den GKE-Cluster oder IAP erreicht.
  • IAP: Im Backend-Dienst aktiviert, um den Zugriff auf Anwendungen mithilfe von IAM-Anmeldedaten zu steuern. IAP erzwingt Zero-Trust-Zugriffsrichtlinien. IAP authentifiziert und autorisiert die KI-Agenten, die auf die Clusterressourcen zugreifen, einschließlich Gemini Enterprise-Apps, benutzerdefinierter Agenten und externer Ressourcen. Aufrufer müssen eine von IAM authentifizierte Identität und eine autorisierte Berechtigung für den Zugriff auf den Backend-Dienst haben.

Wenn Sie Traffic von Ihrem VPC-Netzwerk über ein Gateway an Ihren GKE-Dienst senden, können Sie diesen Traffic mit den folgenden Produkten und Features schützen:

Wenn Sie kein Gateway verwenden, um Traffic von Ihrem VPC-Netzwerk an Ihren GKE-Dienst zu senden, können Sie diesen Traffic mit den folgenden Produkten und Diensten schützen:

Weitere Informationen zum Sichern von GKE finden Sie unter Best Practices für die Netzwerksicherheit und Netzwerksicherheit in GKE.

Netzwerksicherheit für KI-Agenten

Zum Schutz des Netzwerks eines agentischen KI-Systems mit mehreren Agents müssen Sie die Kommunikation sowohl über das VPC-Netzwerk als auch über die API-Oberfläche sichern. Die Datenebene des VPC-Netzwerk regelt, wie Agenten und Tools sicher verbunden werden. Die API-Oberfläche definiert, welche Identitäten und Arten von Datenaustausch zulässig sind. Durch die Schichtung von Zugriffssteuerungen sowohl im VPC-Netzwerk als auch auf der API-Oberfläche wird ein hochgradig kontrollierter und robuster Sicherheitsstatus erzwungen.

Cloud NGFW

Die Cloud NGFW fungiert als Gatekeeper auf Netzwerkebene, um die A2A- und MCP-Kommunikation zu sichern. Die Firewall sorgt dafür, dass nur autorisierter Traffic die Agent-Endpunkte erreichen kann, indem sie jede eingehende oder ausgehende Verbindung zu und von anderen Agenten und Tools überprüft.

Cloud NGFW ist ein verteilter Firewalldienst, der in die VPC-Netzwerkstruktur integriert ist. Es bietet die folgenden Funktionsstufen, die auf verschiedenen Ebenen des Netzwerkstacks funktionieren:

  • Cloud Next Generation Firewall Essentials: Bietet zustandsorientierte Firewall-Paketfilterung. Richtlinienregeln werden anhand von IP-Adressen (L3), Protokollen und Ports (L4) definiert.
  • Cloud Next Generation Firewall Standard: Bietet IP-basierte Erzwingung mit FQDN-Objekten (voll qualifizierter Domainname), Standortbestimmungs-Objekten und Feeds von Google Threat Intelligence, um bekannte schädliche Adressen zu blockieren.
  • Cloud Next Generation Firewall Enterprise: Bietet echte L7-Prüffunktionen mit TLS-Entschlüsselung und IDPS-Funktionen (Intrusion Detection and Prevention System) zur Analyse von Nutzlasten auf erweiterte Bedrohungssignaturen.

Cloud NGFW kann auf das VPC-Netzwerk angewendet werden, um eine Firewallrichtlinie basierend auf Regeln zu erzwingen, die für die von Ihnen verwendete Agent-Hosting-Plattform erforderlich sind.

  • Agent Runtime: Agenten, die in Agent Runtime ausgeführt werden, stellen über Private Service Connect-Netzwerkanhänge eine Verbindung zum VPC-Netzwerk her. Durch diese Anhänge wird die Agent-Netzwerkschnittstelle in einem Subnetz im VPC-Netzwerk angezeigt. Cloud NGFW-Netzwerk-Firewallrichtlinien werden auf das VPC-Netzwerk angewendet. Die Richtlinien filtern den Traffic anhand der Quell-IP-Adressen aus dem Subnetz, das dem Private Service Connect-Netzwerkanhang zugeordnet ist. Für den Traffic-Abgleich können Sie Quell-IP-Adressen und Ziel-IP-Adressbereiche verwenden.
  • Cloud Run: Cloud Run-Dienste, die ausgehenden Direct VPC-Traffic verwenden, senden Traffic direkt von Instanzen, die in einem Subnetz ausgeführt werden, das im VPC-Netzwerk angegeben ist. Cloud NGFW-Netzwerk-Firewallrichtlinien gelten für das Subnetz, das von Cloud Run zum Filtern von Traffic verwendet wird. Für den Traffic-Abgleich können Sie Quell-IP-Adressen und Ziel-IP-Adressbereiche verwenden.
  • GKE: VPC-native GKE-Cluster weisen Pods IP-Adressen zu, die direkt aus den sekundären IP-Adressbereichen des VPC-Netzwerk stammen. Netzwerk-Firewallrichtlinien können Traffic anhand von IP-Adressbereichen für GKE-Knoten und -Pods filtern. Die Richtlinien können sichere Tags und Dienstkonten verwenden. Sichere Tags werden an die VM-Instanzen gebunden, die als GKE-Knoten fungieren. Firewallregeln können dann Traffic von Knoten mit bestimmten Tags als Ziel oder Quelle verwenden. Firewallregeln können auch Traffic von GKE-Knoten basierend auf der Dienstkontoidentität, die mit dem Knotenpool verknüpft ist, als Ziel oder Quelle verwenden.

Standardrichtlinie zum Ablehnen von ausgehendem Traffic

Die Implementierung einer Standard-Ablehnungsstrategie ist eine Best Practice für die Sicherheit, die dem Prinzip der geringsten Berechtigung entspricht. Mit dieser Strategie wird sichergestellt, dass nur explizit zugelassener Netzwerkverkehr erlaubt ist, während der gesamte andere Traffic standardmäßig blockiert wird. Diese Implementierung wird durch die Strukturierung von Firewallregeln mit ALLOW-Regeln mit hoher Priorität für bekannte, legitime Abläufe und einer DENY-Regel mit niedriger Priorität erreicht. Alle Stufen von Cloud NGFW erlauben Regeln basierend auf Quell- und Ziel-IP-Adressbereichen.

Firewallrichtlinienregeln können den Quell-Traffic aus dem Netzwerkanhang-Subnetz der Agent Runtime und dem Direct VPC-Subnetz für ausgehenden Traffic von Cloud Run effektiv abgleichen.

Im Folgenden finden Sie ein Beispiel für eine Standardrichtlinie für ausgehenden Traffic:

  • Netzwerk-Firewallrichtlinie und -regeln erstellen: Erstellen Sie eine globale oder regionale Firewallrichtlinie und verknüpfen Sie sie mit dem VPC-Netzwerk. Erstellen Sie Firewallrichtlinienregeln, die auf Traffic in ausgehender Richtung (--direction=EGRESS) basieren, basierend auf den Quell-IP-Adressbereichen (--src-ip-ranges=SRC_IP_RANGES) und den Ziel-IP-Adressbereichen (--dest-ip-ranges=DEST_IP_RANGES).
  • Spezifische ALLOW-Regeln: Verwenden Sie niedrigere Prioritätsnummern, z. B. 100–1.000. Diese Regeln lassen genau den Netzwerkverkehr zu, der für die Funktion Ihrer KI-Agenten erforderlich ist. Dieser Traffic umfasst die Kommunikation mit anderen internen Diensten, Load Balancern, erforderlichen Google APIs oder legitimen externen Endpunkten. Erstellen Sie eine Regel, die den Quell-Traffic aus dem Netzwerkanhang-Subnetz der Agent Runtime oder aus dem Direct VPC-Egress-Subnetz von Cloud Run mit den gewünschten Zielen abgleicht.
  • Allgemeine DENY-Regel: Damit die Regel in der Auswertungsreihenfolge an letzter Stelle steht, verwenden Sie die höchste Prioritätsnummer, z. B. 2147483647. Diese Regel lehnt Traffic an alle Ziele (--dest-ip-ranges=0.0.0.0/0) ab, die mit keiner der vorherigen ALLOW-Regeln übereinstimmen.

Eine Standardrichtlinie zum Ablehnen von ausgehendem Traffic verhindert, dass KI-Agenten Netzwerkverbindungen herstellen, die nicht explizit autorisiert sind. Außerdem werden potenzielle Daten-Exfiltrationen oder Zugriffe auf schädliche Websites blockiert. Die Richtlinie beschränkt die gehosteten Agenten darauf, nur mit genehmigten Endpunkten zu kommunizieren. Das ist entscheidend, um die Kontrolle über autonome Arbeitslasten zu behalten.

Zusätzliche Überlegungen zu Cloud NGFW-Richtlinien

Zusätzlich zur Standardstrategie „Ablehnen“, die in allen Cloud NGFW-Stufen verfügbar ist, können Sie die Netzwerksicherheit Ihrer Multi-Agenten-KI mit kostenpflichtigen Funktionen weiter verbessern:

  • Cloud NGFW Standard-Funktionen:
    • FQDN-Objekte für dynamische Endpunkte: KI-Agenten interagieren häufig mit externen APIs, Modellendpunkten oder Datenquellen, deren IP-Adressen sich ändern können. Verwenden Sie FQDN-Objekte in ALLOW-Regeln, um einen konsistenten Zugriff auf erforderliche Dienste nach Domainnamen zu ermöglichen.
    • Standortbestimmung: Wenn für KI-Agenten Compliance-Anforderungen gelten oder sie nicht mit Diensten in bestimmten geografischen Regionen interagieren sollen, verwenden Sie Standortobjekte (--src-region-codes=SRC_COUNTRY_CODES) in Ihren Firewallregeln, um den Traffic zu oder von diesen Standorten einzuschränken.
    • Google Threat Intelligence: Verwenden Sie Google Threat Intelligence in Filtern für ausgehenden Traffic, um automatisch zu verhindern, dass Agenten Verbindungen zu bekannten bösartigen Zielen herstellen, z. B. Command and Control-Servern (C2), Anonymisierungsdiensten wie Tor und Websites, die Malware verbreiten. Die Verwendung von Google Threat Intelligence hilft, die Auswirkungen eines potenziell manipulierten Agenten einzudämmen. Wir empfehlen, diese Zielfilter in die DENY-Regeln mit der höheren Prioritätsnummer (niedrigere Auswertungsreihenfolge) aufzunehmen.
  • Cloud NGFW Enterprise-Features:
    • Layer-7-Prüfung: Bei Agents, die sensible Daten verarbeiten oder höheren Risiken ausgesetzt sind, sollten Sie die Paketnutzlasten auf Bedrohungen wie Malware, Spyware und Exploits prüfen, die nicht von Firewallregeln auf Netzwerkschicht analysiert werden.
    • TLS-Prüfung: Aktivieren Sie die TLS-Prüfung, damit die Prüf-Engine verschlüsselten Traffic analysieren kann. Die Verwendung der TLS-Prüfung ist entscheidend, da die meisten modernen Angriffe und die C2-Kommunikation verschlüsselt sind.

Weitere Informationen zu Implementierungsaspekten oder Einschränkungen, die für Ihre Umgebung gelten könnten, finden Sie in den folgenden Ressourcen:

IAP

IAP sichert eingehende Anfragen an GKE-Cluster, indem es eine zentrale Authentifizierungs- und Autorisierungsebene für KI-Apps bereitstellt. IAP fängt alle HTTPS-Anfragen ab, die für das Gateway bestimmt sind, und prüft die Identität und Berechtigungen des Aufrufers. IAP lässt nur authentifizierte und autorisierte Anfragen an die Arbeitslast des Backend-Dienstes zu. IAP auf dem Gateway-Load-Balancer schützt nur Traffic, der von außerhalb des Clusters kommt. Die Kommunikation innerhalb des Clusters erfolgt nicht über IAP.

Für den Zugriff auf KI-Apps, die in GKE gehostet und durch IAP geschützt werden, muss den Hauptnutzeridentitäten die IAM-Rolle „Nutzer von IAP-gesicherten Web-Apps“ (roles/iap.httpsResourceAccessor) für die durch IAP geschützte Backend-Dienstressource zugewiesen werden. Wir empfehlen, ein benutzerdefiniertes Dienstkonto als Identität für bereitgestellte Agenten zu konfigurieren. Mit einem benutzerdefinierten Dienstkonto können Sie Berechtigungen nach dem Prinzip der geringsten Berechtigung genauer zuweisen.

Weisen Sie die IAM-Rolle „IAP-secured Web App User“ nur den Dienstkonten von KI-Agenten direkt zu, die auf andere KI-Agenten und Tools zugreifen dürfen, die im GKE-Dienst gehostet werden, auf den die benutzerdefinierte Ressource GCPBackendPolicy (oder BackendConfig für Ingress) verweist. Wenn Sie Gemini Enterprise-Apps Zugriff gewähren möchten, binden Sie die IAM-Rolle Discovery Engine-Dienstkonto (roles/discoveryengine.serviceAgent) für Ihr Gemini Enterprise-Projekt.

VPC Service Controls

VPC Service Controls minimiert das Risiko einer Daten-Exfiltration, indem der Zugriff auf Google APIs streng kontrolliert wird. Wir empfehlen, einen einzelnen Makroperimeter bereitzustellen, der alle unterstützten Dienste umfasst. Dieser Ansatz bietet den robustesten Schutz vor Exfiltration. Um eine konsistente Richtlinienerzwingung für gemeinsam genutzte VPC-Architekturen zu gewährleisten, ist es wichtig, sowohl das Hostprojekt als auch alle zugehörigen Dienstprojekte in denselben Dienstperimeter aufzunehmen.

Beachten Sie die folgenden Empfehlungen, um die Interaktion zwischen Gemini Enterprise und Cloud Run über Projektgrenzen hinweg zu sichern:

  • Stellen Sie einen einzelnen VPC Service Controls-Perimeter bereit, der sowohl die Gemini Enterprise- als auch die Cloud Run-Projekte umfasst.
  • Fügen Sie alle unterstützten VPC Service Controls-Dienste der Liste der eingeschränkten Dienste hinzu. So lassen sich nicht autorisierte administrative Änderungen verhindern.
  • Erzwingen Sie interne Einstellungen für eingehenden Traffic und Autorisierung, um den gesamten öffentlichen Internetzugriff auf Ihre Cloud Run-Dienste zu blockieren.

Cloud Run-Dienste sind durch IAM gesichert. Aufrufer müssen authentifiziert sein und die IAM-Rolle Cloud Run-Aufrufer (roles/run.invoker) für den Zieldienst haben. Die Rolle wird durch Validieren eines Tokens aus dem Header Authorization (oder dem Header X-Serverless-Authorization, wenn Gemini Enterprise eine Standard-.run.app-URL aufruft) geprüft. Damit der Cloud Run-Dienst erfolgreich aufgerufen werden kann, muss Dienstkonten, z. B. solchen, die von Gemini Enterprise verwendet werden, auch die Rolle „Cloud Run-Invoker“ zugewiesen werden.

Wenn Gemini Enterprise und Cloud Run in verschiedenen Projekten bereitgestellt werden, ist ein VPC Service Controls-Perimeter erforderlich, um den eingehenden Cloud Run-Traffic auf „Intern“ festzulegen. Ohne diesen Perimeter werden projektübergreifende Aufrufe von Gemini Enterprise als externer Traffic behandelt. Dadurch müssen Sie den eingehenden Cloud Run-Traffic auf „Alle“ festlegen, wodurch der Dienst dem öffentlichen Internet ausgesetzt ist.

  • Der eingehende Cloud Run-Traffic all wird unterstützt, wenn beide der folgenden Bedingungen erfüllt sind:
    • VPC Service Controls ist nicht aktiviert.
    • Cloud Run und Gemini Enterprise befinden sich nicht im selben Projekt.
  • Für alle anderen Konfigurationen wird nur der Cloud Run-Ingress internal unterstützt.

Zusätzliche Überlegungen zu VPC Service Controls

Wenn Cloud Run innerhalb eines VPC Service Controls-Perimeters bereitgestellt wird, empfehlen wir, die folgenden Richtlinien-Guardrails zu implementieren, um einen umfassenden Schutz zu gewährleisten:

  • Zulässige Einstellungen für eingehenden Traffic einschränken: Verhindern Sie, dass Entwickler versehentlich öffentliche Endpunkte bereitstellen, indem Sie die Organisationsrichtlinien-Einschränkung run.allowedIngress festlegen. Diese Einschränkung gilt nur für neue Bereitstellungen. Frühere Bereitstellungen sind möglicherweise nicht konform. Wir empfehlen, alle vorhandenen Cloud Run-Dienste innerhalb des Perimeters zu prüfen und alle Dienste, die die erforderlichen Einstellungen für eingehenden und ausgehenden Traffic nicht erfüllen, neu bereitzustellen oder zu aktualisieren.
    • Wenn Sie nur interne Anfragen zulassen möchten, legen Sie den Wert auf internal fest.
    • Wenn Sie Anfragen über einen externen Application Load Balancer zulassen möchten, legen Sie den Wert auf internal-and-cloud-load-balancing fest.
  • Zulässige Einstellungen für ausgehenden VPC-Traffic einschränken: Wenn Sie alle ausgehenden Anfragen über die VPC weiterleiten möchten, damit sie von Perimeter-Firewallregeln geprüft werden können, setzen Sie den Wert der Organisationsrichtlinien-Einschränkung run.allowedVPCEgress auf all-traffic. Diese Einstellung erfordert, dass jede Cloud Run-Überarbeitung direkten ausgehenden VPC-Traffic oder einen Connector für Serverloser VPC-Zugriff verwendet. Diese Einschränkung gilt nur für neue Bereitstellungen. Frühere Bereitstellungen sind möglicherweise nicht konform. Wir empfehlen, alle vorhandenen Cloud Run-Dienste innerhalb des Perimeters zu prüfen und alle Dienste, die die erforderlichen Einstellungen für eingehenden und ausgehenden Traffic nicht erfüllen, neu bereitzustellen oder zu aktualisieren.
  • Container-Images und Dienste am selben Ort speichern: Das Artifact Registry-Repository, das Ihre Container-Images enthält, muss sich im selben Perimeter wie der Cloud Run-Dienst befinden. Das perimeterübergreifende Abrufen von Images wird automatisch blockiert, es sei denn, Sie legen explizite Regeln für eingehenden und ausgehenden Traffic fest.
  • Zugriffsebenen verwalten: Regeln von VPC Service Controls-Richtlinien für eingehenden Traffic und Zugriffsebenen, die auf IAM-Hauptkontoidentitäten basieren, werden für Cloud Run-Aufrufe nicht unterstützt. Stattdessen müssen Sie den Zugriff mit netzwerkbasierten Kriterien oder gerätebasierten Zugriffsebenen verwalten.

Model Armor

Model Armor ist ein API-basierter Dienst, der die Sicherheit von KI-Apps verbessert. KI-Agenten interagieren mit Model Armor, indem sie Aufrufe senden, um Nutzer-Prompts zu bereinigen, bevor sie an ein LLM gesendet werden, und um Modellantworten zu bereinigen, bevor sie an den Nutzer zurückgegeben werden. Model Armor prüft LLM-Prompts und ‑Antworten aktiv. Das ist ein wichtiger Prüfpunkt, um neue Risiken zu erkennen, und ein Kontrollpunkt, um Standards für verantwortungsbewusste KI zu implementieren. Wir empfehlen, Model Armor zu verwenden, um die Einhaltung von Anforderungen an den Datenspeicherort und von gesetzlichen Bestimmungen zur Datenhoheit zu gewährleisten. Wenn Sie Model Armor innerhalb eines VPC Service Controls-Perimeters verwenden möchten, müssen Sie einen Private Service Connect-Endpunkt für den regionalen Model Armor-Endpunkt in Ihrem VPC-Netzwerk konfigurieren.

Model Armor ist ein regionaler Dienst, auf den privat über regionale Private Service Connect-Endpunkte im VPC-Netzwerk zugegriffen wird. Der Dienst us-central1 wird beispielsweise über den regionalen Endpunkt modelarmor.us-central1.rep.googleapis.com aufgerufen. Regionale Endpunkte helfen, den Datenstandort zu gewährleisten.

Wenn Sie den Zugriff für KI-Agenten aktivieren möchten, konfigurieren Sie die folgenden Komponenten in jeder Region, in der der Model Armor-Dienst erforderlich ist:

  1. Erstellen oder identifizieren Sie ein RFC 1918-Subnetz in der VPC-Netzwerkregion, in der sich der Model Armor-Dienst befindet.
  2. Erstellen Sie einen regionalen Endpunkt im RFC 1918-Subnetz.
  3. Erstellen Sie eine private Cloud DNS-Zone und einen Eintrag für den Hostnamen des regionalen Model Armor-Endpunkts (z. B. modelarmor.us-central1.rep.googleapis.com), der in die IP-Adresse des regionalen Endpunkts aufgelöst wird.
  4. Richten Sie für die Interoperabilität von Agent Runtime ein DNS-Peering von Agent Runtime zur privaten Cloud DNS-Zone ein, die mit Ihrem VPC-Netzwerk verknüpft ist. Wenn Agenten Anfragen an Model Armor senden, löst Cloud DNS die Hostnamenanfragen in die IP-Adresse des regionalen Private Service Connect-Endpunkts im VPC-Netzwerk auf. Dieser Schritt ist für KI-Agenten, die in Cloud Run und GKE gehostet werden, nicht erforderlich.

Wenn Sie Gemini Enterprise in Model Armor einbinden möchten, erstellen Sie eine Model Armor-Vorlage im selben Projekt wie Gemini Enterprise. Der Speicherort der Vorlage und der Gemini Enterprise-App muss identisch sein.

Weitere Informationen zum Aktivieren von Model Armor finden Sie in den folgenden Ressourcen:

Cloud Armor

Cloud Armor ist ein verteilter Netzwerksicherheitsdienst, der Anwendungen und Dienste hinter Load Balancern schützt, bevor Anfragen die Laufzeiten von Backend-Diensten erreichen. Arbeitslasten von KI-Agenten umfassen ein hohes Volumen an Kommunikation zwischen Diensten, die A2A-, MCP- und API-Aufrufe verwenden. Der Cloud Armor-Schutz bietet zusätzliche Resilienz im Sicherheitsdesign mit Ratenbegrenzung, WAF-Prüfung und benutzerdefinierten Regeln, die den erwarteten agentischen Anfragen entsprechen. Wenn Sie Cloud Armor-Sicherheitsrichtlinien an Application Load Balancer-Backend-Dienste anhängen, kann der Traffic nach schädlichen Anfragen gefiltert und mit Ratenbegrenzungen überwacht werden. Außerdem können DDoS-Angriffe abgewehrt werden.

Cloud Armor kann in den folgenden Szenarien in einer Agent-Netzwerkarchitektur bereitgestellt werden:

  • Cloud Run mit internem Application Load Balancer: Schützen Sie Agenten und Tools, die in Cloud Run ausgeführt werden, indem Sie einen internen Application Load Balancer mit serverlosen NEG-Backends verwenden. Wenden Sie Backend-Sicherheitsrichtlinien auf die serverlose NEG an, um WAF-Regeln für internen Traffic und Ratenbegrenzung zu erzwingen. Zur Steuerung der Agent-Kommunikation können Sie zusätzliche benutzerdefinierte Regeln basierend auf IP-Adressen und Headern definieren.
  • Gateway: Schützen Sie Agenten und Tools, die in GKE ausgeführt werden, indem Sie eine Gateway-Ressourcendefinition für einen globalen oder regionalen externen Application Load Balancer mit zonalen NEG-Backends verwenden. Verwenden Sie die Kubernetes Gateway API, um die Ressource GCPBackendPolicy mit der definierten Cloud Armor-Sicherheitsrichtlinie anzuwenden. Wenn Sie einen regionalen externen Application Load Balancer verwenden, unterstützt Cloud Armor Backend-Sicherheitsrichtlinien mit WAF-Regeln, IP-Adressen und standortbasierten Kontrollen sowie Ratenbegrenzung. Globale externe Application Load Balancer unterstützen Backend-Sicherheitsrichtlinien und zusätzliche Edge-Sicherheitsrichtlinien mit Google Cloud Armor Adaptive Protection und Google Threat Intelligence.

Sicherer Web-Proxy

Secure Web Proxy ist ein regionaler verwalteter Dienst, der im VPC-Netzwerk bereitgestellt wird, um HTTP/S-Traffic zu filtern, der im VPC-Netzwerk oder in verbundenen Netzwerken entsteht. Er fungiert als zentraler Proxy und Sicherheitserzwingungspunkt, um eine detaillierte Kontrolle und Sichtbarkeit für ausgehenden Internettraffic zu ermöglichen. Er fungiert auch als expliziter Proxy für die interne Dienstkommunikation.

Secure Web Proxy unterstützt drei Bereitstellungsmodi: expliziter Proxy-Routing-Modus, Private Service Connect-Dienstanhangsmodus und Next-Hop-Modus. Wir empfehlen, Secure Web Proxy im expliziten Proxy-Routing-Modus zu verwenden, der im Mittelpunkt dieses Dokuments steht. In diesem Modus müssen HTTP-Clients explizit so konfiguriert werden, dass sie direkt auf die IP-Adresse oder den Hostnamen des Secure Web Proxy verweisen.

Wenn Sie Secure Web Proxy in Ihrem VPC-Netzwerk bereitstellen möchten, müssen Sie ein Frontend-Subnetz und ein Nur-Proxy-Subnetz konfigurieren. Secure Web Proxy ist ein vollständig verwalteter Dienst. Wenn Secure Web Proxy bereitgestellt wird, werden Cloud Router und Cloud NAT automatisch in Ihrem VPC-Netzwerk bereitgestellt und konfiguriert, um eine spezifische Integration mit der Proxy-Ressource zu ermöglichen. Diese Konfiguration schreibt vor, dass alle ausgehenden Anfragen den Secure Web Proxy passieren müssen, bevor sie ins Internet gelangen.

Wenn Sie Secure Web Proxy als expliziten Proxy verwenden, werden Agent-Anfragen unterstützt, die von Private Service Connect-Schnittstellen der Agent Runtime, ausgehendem Direct VPC-Traffic von Cloud Run und VPC-nativen GKE-Clustern stammen. Wenn Agents Anfragen mit der HTTP-Methode CONNECT an Secure Web Proxy senden, wird der TCP-Sitzungstraffic an den Proxy getunnelt, wo Sicherheitsrichtlinienregeln angewendet werden. Wenn der Traffic zulässig ist, sendet Secure Web Proxy den Traffic an den kontrollierten ausgehenden Internet-Traffic oder an private Netzwerkziele, die vom VPC-Netzwerk weitergeleitet werden können.

Explizites Proxy-Routing

Für ausgehenden Traffic von Agent Runtime ist eine explizite Proxy-Konfiguration erforderlich, damit Agenten Internetziele oder nicht routingfähige IP-Adressbereiche im VPC-Netzwerk erreichen können. Für die Interoperabilität mit Agent Runtime empfehlen wir, die Secure Web Proxy-Ressource mit einer RFC 1918-IP-Adresse aus einem Frontend-Subnetz im VPC-Netzwerk zu konfigurieren. Mit dieser Konfiguration ist Secure Web Proxy direkt über die Agent Runtime erreichbar. Anschließend können alle Verbindungen zu nicht routingfähigen IP-Adresszielen im VPC-Netzwerk oder in verbundenen Netzwerken über einen Proxy weitergeleitet werden.

Konfigurieren Sie die folgenden Netzwerkressourcen, um die Verwendung von Secure Web Proxy im expliziten Routingmodus durch die Agent-Hosting-Plattform zu unterstützen:

  1. Erstellen oder identifizieren Sie ein RFC 1918-Subnetz im VPC-Netzwerk, um die Secure Web Proxy-Ressource zu hosten.
  2. Erstellen Sie einen Cloud DNS-Eintrag für den Secure Web Proxy-Hostnamen (z. B. swp.example.com), der in die IP-Adresse der Secure Web Proxy-Ressource aufgelöst wird.
  3. Richten Sie für die Interoperabilität von Agent Runtime ein DNS-Peering von Agent Runtime zur privaten Cloud DNS-Zone ein, die mit Ihrem VPC-Netzwerk verknüpft ist. Wenn Agents Anfragen an den Secure Web Proxy senden, löst Cloud DNS die Hostnamenanfragen in die IP-Adresse der Secure Web Proxy-Ressource im VPC-Netzwerk auf. Dieser Schritt ist für KI-Agenten, die in Cloud Run und GKE gehostet werden, nicht erforderlich.

Proxy-Einstellungen für KI-Agenten

Die Standardmethode zum Konfigurieren von Agent-Anwendungen für die Verwendung eines HTTP(S)-Proxys besteht darin, diese Umgebungsvariablen festzulegen:

  • HTTP_PROXY: Die URL des expliziten Proxyservers für HTTP-Traffic (z. B. http://swp.example.com:8888). Bei dieser Einrichtung wird die HTTP-Methode CONNECT vom Client zum Proxy verwendet. Auch wenn HTTP angegeben ist, wird die TLS-Verschlüsselung durchgängig über den Proxy von der Agent Runtime zum Zielendpunkt aufrechterhalten.
  • HTTPS_PROXY: Die URL des expliziten Proxyservers für HTTPS-Traffic (z. B. https://swp.example.com:8888). Wie die Einstellung HTTP_PROXY verwendet die Einstellung HTTPS_PROXY standardmäßig TLS. Sie können jedoch eine zusätzliche Verschlüsselungsebene bereitstellen, indem Sie zusätzlich zur Standard-TLS-Verschlüsselung Ihre eigene TLS-Verschlüsselung aktivieren. Weitere Informationen finden Sie unter Certificate Authority Service.
  • NO_PROXY: Eine durch Kommas getrennte Liste von Hostnamen oder IP-Adressen, die nicht über den Proxy geleitet werden sollen. Wenn Sie beispielsweise metadata.google.internal und 169.254.169.254 zur Liste NO_PROXY hinzufügen, können Arbeitslasten direkt auf den Metadatendienst für die Authentifizierung und Autorisierung bei Google APIs und Google-Diensten zugreifen.

Wenn Sie das Argument env_vars verwenden, um Variablen während der Bereitstellung festzulegen, sind sie in der Agent Runtime-Umgebung verfügbar (z. B. wenn Sie os.environ in Python verwenden). Die meisten Standard-HTTP-Clientbibliotheken erkennen diese Umgebungsvariablen automatisch und verwenden sie, um Traffic über den angegebenen Proxy weiterzuleiten. Dieser Ansatz ist für Python-Anwendungen und HTTP-Clientbibliotheken wie requests üblich. Wenn Sie Agents bereitstellen, definieren Sie Umgebungsvariablen für die Verwendung von Secure Web Proxy für alle privaten Domains, die die Agents erreichen müssen. Achten Sie darauf, dass alle privaten Domainziele auch in Cloud DNS enthalten sind.

Das folgende Beispiel zeigt eine Agent Runtime-Proxy-Bereitstellung aus einem Agent-Objekt:

import agentplatform

client = agentplatform.Client(
    project="PROJECT_ID",
    location="LOCATION",
)

## specify environment variables (dictionary)
env_vars = {
    "OTHER_VARIABLE": "OTHER_VALUE",
    "HTTP_PROXY": "http://swp.example.com:8888",
    "HTTPS_PROXY": "http://swp.example.com:8888",
    "NO_PROXY": "localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"
}

remote_agent = client.runtimes.create(
    agent=local_agent,
    config={
        "display_name": "Example agent using proxy",
        "env_vars": env_vars,
        ## ... other configs
    },
)

Cloud Run unterstützt das Festlegen von Umgebungsvariablen auf der Ebene der Dienstrevision. Bei diesem Ansatz werden alle Umgebungsvariablen mit demselben Namen überschrieben, die im Container-Image festgelegt wurden. Dieser Ansatz ist nützlich, um Betriebsparameter wie Proxyvariablen beim Start der Dienstinstanzen festzulegen.

Im folgenden Beispiel sehen Sie den Befehl zum Festlegen der Umgebungsvariablen, wenn Sie einen Cloud Run-Dienst bereitstellen:

gcloud run deploy SERVICE_NAME \
--image=IMAGE_URL \
--set-env-vars="HTTP_PROXY=http://swp.example.com:8888,HTTPS_PROXY=http://swp.example.com:8888,NO_PROXY=localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"

Wenn Sie eine explizite Proxy-Konfiguration in GKE-Pods implementieren möchten, definieren Sie eine ConfigMap-Ressource, die die Proxy-Variablen angibt:

apiVersion: v1
kind: ConfigMap
metadata:
  name: agent-proxy-config
  namespace: ai-apps
data:
  HTTP_PROXY: "http://swp.example.com:8888"
  HTTPS_PROXY: "http://swp.example.com:8888"

  NO_PROXY: "localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"

Wenn Sie die ConfigMap-Schlüssel auf die Pods anwenden möchten, verwenden Sie das Feld envFrom im Container-Manifest. Mit dieser Spezifikation werden die Umgebungsvariablen zur Laufzeit in den Container eingefügt.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: subagent-app
spec:
  template:
    spec:
      containers:
      -   name: my-container
        image: my-agent-app:latest
        envFrom:
        -   configMapRef:
            name: agent-proxy-config

CA-Dienst

CA Service ist erforderlich, wenn Secure Web Proxy oder Cloud NGFW für die TLS-Prüfung konfiguriert ist. Wenn die TLS-Prüfung aktiviert ist und das Ziel einer Arbeitslast TLS verwendet, erstellt und signiert der CA-Dienst ein Zertifikat für dieses Ziel. Wenn der verschlüsselte Traffic für das tatsächliche Ziel bei Secure Web Proxy oder Cloud NGFW ankommt, wird das Paket entschlüsselt, geprüft und dann werden Richtlinien erzwungen. Wenn die Richtlinien das Paket zulassen, verschlüsselt der Dienst das Paket für das endgültige Ziel neu. Sie können CA Service auch verwenden, um Zertifikate für andere von Google verwaltete Dienste bereitzustellen.

CA Service ist ein verwalteter Dienst. Nachdem der CA-Dienst konfiguriert wurde, übernimmt er die Signierung von untergeordneten Zertifikaten, bis das Root-CA-Zertifikat abläuft. Root-CA-Zertifikate müssen aktualisiert werden, damit sie nicht ablaufen.

Der CA Service unterstützt die folgenden Funktionen, um die Traffic-Prüfung und Zertifikatsverwaltung in einer KI-Architektur mit mehreren Agenten in großem Umfang zu ermöglichen:

  • TLS-Prüfung: Für die vollständige TLS-Prüfung ist eine private Zertifizierungsstelle erforderlich. Um HTTPS-Nutzlasten vollständig zu entschlüsseln und zu analysieren, muss das zwischengeschaltete Proxy-Gerät (Secure Web Proxy oder Cloud NGFW) die TLS-Sitzung mit dem Client beenden. Der Proxy muss ein gültiges Zertifikat vorweisen, das der Client als vertrauenswürdig für die angeforderte Domain akzeptiert.

    CA Service kann dynamisch ein standortspezifisches Identitätswechselzertifikat für die angeforderte Website generieren und signieren. Wenn auf dem Client das private Root-CA-Zertifikat im Trust Store installiert ist, wird dieses dynamisch erstellte Zertifikat als gültig akzeptiert. Der Client vertraut dem vom Proxy gesendeten Zertifikat und sendet die Anfrage. Der Proxy beendet die TLS-Sitzung, entschlüsselt das Paket, prüft den Inhalt und erzwingt dann Richtlinien.

  • Zertifikatsverteilung: Interne Clientressourcen wie KI-Agenten, die in Agent Runtime, Cloud Run oder GKE ausgeführt werden, benötigen das private Root-CA-Zertifikat in ihren lokalen Trust Stores. Wenn Sie den öffentlichen Schlüssel des Root-CA-Zertifikats in Secret Manager speichern, können KI-Agenten das Zertifikat beim Start abrufen und ihrem System-Trust-Store hinzufügen.

    Interne Serverressourcen wie interne Application Load Balancer benötigen Zertifikate, die von der privaten Zertifizierungsstelle ausgestellt wurden, um als vertrauenswürdige Serverendpunkte zu fungieren und Client-TLS-Sitzungen zu beenden. Application Load Balancer werden in die Ausstellungskonfigurationen des Zertifikatmanagers eingebunden, um die Signierung der Zertifikatsanfrage durch den CA Service und die Bereitstellung auf dem Load Balancer zu automatisieren.

Weitere Informationen zu Zertifikatsvorgängen finden Sie in den folgenden Ressourcen:

Sicherheit der A2A-Verbindung

Root-Agenten kommunizieren mit einer Vielzahl von Sub-Agenten und MCP-Servern, die auf verschiedenen Laufzeit-Hosting-Plattformen bereitgestellt werden. Jede Umgebung hat eigene Netzwerk- und Sicherheitsanforderungen, die von der A2A- oder MCP-Ebene abstrahiert werden müssen.

Das folgende Diagramm zeigt die Komponenten und möglichen Verbindungspfade, die von diesem Designleitfaden unterstützt werden:

Agent2Agent-Verbindungsmuster (A2A) zwischen verschiedenen Hostingplattformen, einschließlich GKE, Cloud Run und Agent Runtime, sowie Verbindungen zu MCP-Servern und dem Internet.

Das obige Diagramm fasst diese Verbindungsmöglichkeiten zusammen:

  • Nutzer interagieren mit dem agentischen System über eine Gemini Enterprise-App.
  • Die Gemini Enterprise App verwendet die Google-Infrastruktur, um eine Verbindung zu einem Root-Agenten herzustellen, der in GKE, Cloud Run oder Agent Runtime ausgeführt wird.
  • Die Gemini Enterprise App und die Root-Agenten verwenden die Google-Infrastruktur, um eine Verbindung zu Model Armor und dem Gemini-LLM auf der Agent Platform herzustellen.
  • Die Root-Agenten können die Google-Infrastruktur verwenden, um eine Verbindung zu Sub-Agenten herzustellen, die in Cloud Run oder Agent Runtime ausgeführt werden.
  • Die Root-Agenten können private IP-Adressen verwenden, um eine Verbindung zu Sub-Agenten herzustellen, die in Agent Runtime, Cloud Run und GKE ausgeführt werden. Diese Verbindungen müssen über ein VPC-Netzwerk weitergeleitet werden.
  • Sowohl Stamm- als auch Unter-Agenten können eine Verbindung zu MCP-Servern herstellen, die in Cloud Run oder GKE ausgeführt werden. Agenten, die eine Verbindung zu den MCP-Servern herstellen, können entweder die Google-Infrastruktur oder ein VPC-Netzwerk verwenden. Die MCP-Server bieten Zugriff auf Tools, die inGoogle Cloud, lokal, in einer anderen Cloud oder im Internet gehostet werden.
  • Dienste, die im Internet gehostet werden, können direkt über Secure Web Proxy erreicht werden.

In den folgenden Abschnitten finden Sie Ressourcen für die Laufzeitdatenpfade und Sicherheitskontrollen, die für sichere A2A-Interaktionen erforderlich sind. Diese Informationen dienen als Architekturstandard für die Einrichtung privater Konnektivität und die Implementierung der mehrschichtigen Abwehrmaßnahmen, die zum Schutz des End-to-End-Datenpfads zwischen Agenten erforderlich sind.

GKE-Quell-Agent

In der folgenden Tabelle finden Sie Ressourcen, mit denen Sie Traffic schützen können, wenn GKE der Quell-Agent ist. Dieser Traffic wird über das VPC-Netzwerk geleitet, in dem der GKE-Cluster gehostet wird.

Ziel-Agent (Datenpfad) Sicherheitskontrollen
Agent Runtime (intern)
Cloud Run (intern)
Cloud Run (Private Service Connect für Google APIs)
Cloud Run-Zugriff (serverlose NEG)
GKE
Internet über VPC-Netzwerk

Agent Runtime (interner) Quell-Agent

In der folgenden Tabelle finden Sie Ressourcen, mit denen Sie den Traffic schützen können, wenn Agent Runtime der Quell-Agent ist und der Traffic direkt über die Google-Infrastruktur geleitet wird. An diesen Pfaden ist kein VPC-Netzwerk beteiligt.

Ziel-Agent (Datenpfad) Sicherheitskontrollen
Agent Runtime (intern)
Cloud Run (intern)

Agent Runtime-Quell-Agent (Private Service Connect-Schnittstelle)

In der folgenden Tabelle finden Sie Ressourcen, mit denen Sie Traffic schützen können, wenn Agent Runtime der Quell-Agent ist und der Traffic über eine Private Service Connect-Schnittstelle durch ein VPC-Netzwerk geleitet wird.

Ziel-Agent (Datenpfad) Sicherheitskontrollen
Cloud Run (Private Service Connect für Google APIs)
Cloud Run-Zugriff (serverlose NEG)
GKE
Internet über VPC-Netzwerk

Cloud Run-Quell-Agent (intern)

In der folgenden Tabelle finden Sie Ressourcen, mit denen Sie Traffic schützen können, wenn Cloud Run der Quell-Agent ist und der Traffic direkt über die Google-Infrastruktur geleitet wird. An diesen Pfaden ist kein VPC-Netzwerk beteiligt.

Ziel-Agent (Datenpfad) Sicherheitskontrollen
Agent Runtime (intern)
Cloud Run (intern)

Cloud Run-Quell-Agent (ausgehender Direct VPC-Traffic)

In der folgenden Tabelle finden Sie Ressourcen, mit denen Sie Traffic schützen können, wenn Cloud Run der Quell-Agent ist und der Traffic über Direct VPC-Ausgang durch ein VPC-Netzwerk geleitet wird.

Ziel-Agent (Datenpfad) Sicherheitskontrollen
Cloud Run (Private Service Connect für Google APIs)
Cloud Run-Zugriff (serverlose NEG)
GKE
Internet über VPC-Netzwerk
Agent Runtime (Private Service Connect für Google APIs)

Sicherheit der MCP-Verbindung

In der folgenden Liste sind die Hostingplattformen und die Defense-in-Depth-Kontrollen aufgeführt, die am Schutz des Datenpfads zwischen Agent Runtimes und MCP-Servern beteiligt sind. Verwenden Sie für Quell-Agents in Agent Runtime, Cloud Run oder GKE die folgenden Sicherheitskontrollen, je nach Ziel-MCP-Server:

  • Internet:
    • VPC Service Controls
    • Model Armor
    • Cloud NGFW
    • Sicherer Web-Proxy
  • Google MCP:
    • VPC Service Controls
    • Model Armor

Nächste Schritte

Beitragende

Autor*innen:

  • Deepak Michael | Networking Specialist Customer Engineer
  • Michael Larson | Customer Engineer, Networking Specialist
  • Victor Moreno | Product Manager, Cloud Networking

Weitere Beitragende: