Private Networking-Muster mit mehreren Agents in Google Cloud

Last reviewed 2026-04-16 UTC

In diesem Dokument finden Sie Anleitungen zum Entwerfen einer privaten Netzwerkinfrastruktur, die eine öffentlich zugängliche Gemini Enterprise-App mit mehreren Agenten und privaten Verbindungen zwischen Agenten, Subagenten und Tools unterstützt. Das Netzwerkdesign bietet private Verbindungen für Agents, die in Vertex AI Agent Engine, Cloud Run, Google Kubernetes Engine (GKE), lokalen Rechenzentren oder 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 organisationssensible oder proprietäre Daten. Mit privaten Netzwerken können Sie verhindern, dass dieser Traffic über das öffentliche Internet geleitet wird. Bei diesem Design werden Google Cloud Netzwerkinfrastruktur, VPC-Netzwerkressourcen (Virtual Private Cloud) und private Verbindungen zu lokalen Umgebungen oder Cloud-übergreifenden Netzwerken verwendet.

Im Design, das in diesem Dokument beschrieben wird, 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. Für den Traffic in das und aus dem VPC-Netzwerk werden in diesem Design Private Service Connect-Endpunkte, Private Service Connect-Schnittstellen und der direkte VPC-Ausgang von Cloud Run verwendet. Cloud Next Generation Firewall (Cloud NGFW) steuert den Traffic, der das VPC-Netzwerk durchläuft. Zusätzliche Sicherheitsebenen bieten einen kontrollierten Internet-Ausgang über Secure Web Proxy und API-Dienstzugriffsrichtlinien über einen VPC Service Controls-Perimeter.

Die Zielgruppe für dieses Dokument umfasst Architekten, Entwickler und Administratoren, die Cloud-KI-Infrastrukturen und ‑Apps entwickeln und verwalten. In diesem Dokument wird davon ausgegangen, dass Sie grundlegende Kenntnisse über KI-Agents und -Modelle haben und mit Google Cloud Netzwerkkonzepten vertraut sind.

Designmuster für mehrere Agenten

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

  1. Gemini Enterprise-App, die mit benutzerdefinierten Root-Agents interagiert: Gemini Enterprise-Apps bieten eine verwaltete Benutzeroberfläche mit integrierten Sicherheitsfunktionen, die benutzerdefinierte Agent-Funktionen verfügbar machen. Benutzerdefinierte Root-Agents werden bei Gemini Enterprise registriert und Endnutzern in Apps zur Verfügung gestellt. Der benutzerdefinierte Root-Agent fungiert als Workflow-Orchestrator auf höchster Ebene und delegiert spezialisierte Aufgaben an Sub-Agents. Diese Architektur verwendet benutzerdefinierte Stamm-Agents, die in der Vertex AI Agent Engine, Cloud Run oder GKE gehostet werden.
  2. Root-Agents, die mit Sub-Agents und Tools interagieren: Der Kern des KI-System-Workflows und der Geschäftslogik befindet sich im Root-Agent und in spezialisierten Sub-Agents. Die Flexibilität des Agent-Frameworks, der Laufzeit und der Hostingplattform ermöglicht verschiedene Optionen, um Root-Agents über das VPC-Netzwerk mit Sub-Agents und Tools zu verbinden. Wenn Sie für diesen Teil der Architektur VPC-Netzwerke verwenden, können Agents private Netzwerkpfade nutzen, die Sie definieren und die andere private Endpunkte, Unternehmenssicherheitskontrollen und eine größere Netzwerkreichweite bieten.

Allgemeiner Überblick über eine Multi-Agent-Netzwerkarchitektur.

Die Architektur umfasst die folgenden Komponenten:

  • Gemini Enterprise-App: Das Frontend für Nutzer, um auf eine In-App-Chatoberfläche zuzugreifen und mit dem KI-System mit mehreren Agenten zu interagieren. Nutzer können über das öffentliche Internet oder privat über Hybridverbindungen auf Gemini Enterprise-Apps zugreifen.
  • Benutzerdefinierte Agents: Root-Agents, die mit Gemini Enterprise erstellt und registriert werden und in der Vertex AI Agent Engine, Cloud Run oder GKE gehostet werden. Diese Root-Agents fungieren als Orchestratoren, die Aufgaben an Sub-Agents delegieren.
  • VPC-Netzwerk: Eine Ressource, die Sie steuern, um Agents IP-Netzwerkverbindungen zu privaten Endpunkten und eine breitere Netzwerkreichweite zu ermöglichen. Das VPC-Netzwerk bietet eine Plattform zum Implementieren privater Verbindungen und Netzwerk-Sicherheitskontrollen für Agent-Anfragen an andere Agents und Tools.
  • Untergeordnete Agents: Spezialisierte Agents, die durch den Workflow des Stamm-Agents ausgelöst werden. Untergeordnete Agents kommunizieren über das A2A-Protokoll, das die Interoperabilität zwischen Agents unabhängig von Programmiersprache und Laufzeit ermöglicht.
  • Tools: Remotesysteme, die Dienste wie APIs, Datenquellen und Workflowfunktionen bereitstellen. Über diese Tools rufen Agenten Daten ab und verarbeiten Aktionen oder Transaktionen. Tools sind extern für Agenten. Agenten stellen eine Verbindung zu Tools her und interagieren mit ihnen, indem sie die MCP-Spezifikation verwenden.

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

Freigegebene VPC

Beim Multi-Agent-Entwurfsmuster wird eine freigegebene VPC verwendet, um die Netzwerk- und Sicherheitsautorität und -verantwortung 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 freigegebenen 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-Laufzeitressourcen, einschließlich Vertex AI Agent Engine, Cloud Run, GKE, Gemini Enterprise und anwendungsspezifischer Load Balancer.

Bei der freigegebene VPC wird eine klare Grenze zwischen Netzwerk- und Sicherheitsadministratoren und KI-App-Entwicklern durchgesetzt:

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

Wenn Sie Netzwerk- und Sicherheitsbereitstellungen in einem Hostprojekt zentralisieren, schaffen Sie einen zentralen Verwaltungspunkt für die Kommunikation zwischen Agents und zwischen Agents und Diensten. Dieses Design vereinfacht die Durchsetzung von Sicherheitsrichtlinien in vielen verschiedenen Dienstprojekten und sorgt gleichzeitig für eine konsistente Konnektivität.

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

Anfragen, die von benutzerdefinierten Stamm-Agents initiiert werden, verwenden ein privates, vom Kunden verwaltetes VPC-Netzwerk, um sichere Netzwerkpfade zu Sub-Agents, Tools und Diensten bereitzustellen. Das VPC-Netzwerkrouting bestimmt 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 der Verbindung zu Folgendem:

  • Andere VPC-Netzwerke über VPC-Netzwerk-Peering, Appliances mit mehreren NICs oder NCC.
  • Private Service Connect-Endpunkte für den Zugriff auf Diensterstellerdienste.
  • Verwaltete Dienste mit privaten IP-Adressen, z. B. Cloud SQL.
  • Front-Ends für interne Load Balancer und Compute Engine-Ressourcen.
  • Google APIs über den privater Google-Zugriff oder über Private Service Connect.
  • Das Internet, das über Secure Web Proxy gesteuert wird.
  • Hybrid- und Cross-Cloud-Ziele über Cloud Interconnect, Cloud VPN, Router-Appliance oder SD-WAN.
  • Jedes Endpunktziel, das über das IP-Routing des VPC-Netzwerk erreichbar ist.
  • Andere KI-Agents, Tools und unterstützende Dienste.

Weitere Informationen zur 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 Netzwerkkommunikation zwischen dem Nutzer und der Gemini Enterprise-App sowie zwischen der App und den Agents beschrieben.

Nutzerchats mit Gemini Enterprise-Apps

Nutzer interagieren mit der Gemini Enterprise-App über eine browserbasierte App, die Anfragen an Google-APIs und -Dienste sendet. Um private Nutzerverbindungen zu ermöglichen, 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-Apps 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 von Vertex AI Agent Engine oder der A2A-Agenten-URL. Gemini Enterprise-Apps haben eine integrierte Chatoberfläche, die Assistent genannt wird. Wenn ein Nutzer einen Agenten mit @agent_name angibt oder der Assistent sich für die Delegation entscheidet, sucht die App den Agenten in der Registrierung, 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 Agents in Vertex AI Agent Engine und in Cloud Run können vorhandene private Netzwerkpfade verwenden, ohne dass zusätzliche Netzwerkressourcen konfiguriert werden 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 von Vertex AI. Der Netzwerkpfad und die Autorisierungsmechanismen unterscheiden sich je nach verwendeter Hostingplattform:

  • Benutzerdefinierte KI-Agents in Vertex AI Agent Engine: Der Vertex AI Discovery Engine-Dienst-Agent enthält die erforderlichen Vertex AI Identity and Access Management-Rollen (IAM), um Vertex AI Agent Engine-Ressourcen als integrierte Funktion aufzurufen. Das System leitet Anfragen, die an den Vertex AI API-Dienst gerichtet sind, über das Google-Netzwerk als internen API-Aufruf weiter.
  • Benutzerdefinierte Agenten in Cloud Run: Gemini Enterprise-Apps verwenden die Dienst-Agentenidentität von Vertex AI Discovery Engine, um Aufrufe an die stabile run.app-URL zu senden, die über die Agentenkarte registriert ist. Damit der Cloud Run-Dienst des KI-Agents diese Aufrufe autorisieren kann, müssen Sie dem Discovery Engine-Dienst-Agent die IAM-Rolle „Cloud Run Invoker“ (roles/run.invoker) zuweisen. Anfragen an Cloud Run werden über das Google-Produktionsnetzwerk an den Google Front End (GFE) für Cloud Run-Ingress weitergeleitet.

  • Benutzerdefinierte Agenten in GKE: Gemini Enterprise-Apps verwenden die Identität des Vertex AI Discovery Engine-Dienst-Agents, um Aufrufe an die URL zu senden, die auf der Agentenkarte registriert ist. Der öffentliche DNS muss den Hostnamen in eine externe IP-Adresse auflösen können, die vom Gateway verwaltet wird. Wir empfehlen die Verwendung des gke-l7-regional-external-managed Load-Balancers oder des gke-l7-global-external-managed-Load-Balancers. Zur Erhöhung der 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-Agent 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 Ingress des externen Application Load Balancer weiter.

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

Private Netzwerke für Agent-Hosting-Plattformen

Nachdem ein Nutzer eine Anfrage an die Gemini Enterprise-App gesendet hat, werden Anfragen von benutzerdefinierten Stamm-Agents an untergeordnete Agents und Tools gesendet. Die benutzerdefinierten Plattformen für das Hosten von Agents stellen die Schnittstelle zwischen Gemini Enterprise und Ihren VPC-Netzwerken bereit. Die Hostingplattformen für Ihre containerisierten Agents und Tools sind Vertex AI Agent Engine, Cloud Run und GKE.

Bei der Auswahl einer Plattform für das Hosting von KI-Agenten müssen Sie die Muster für private Netzwerke, Sicherheitsfunktionen, Verwaltungsfunktionen, den Grad der Anpassung und die Sicherheits-Compliance der einzelnen Plattformen berücksichtigen. Weitere Informationen zur Auswahl einer Hostingplattform für KI-Agents finden Sie unter Modelle und Infrastruktur für Ihre generative KI-Anwendung auswählen und Komponenten für die Architektur von agentischer KI auswählen.

Sie stellen private VPC-Verbindungen über verschiedene Mechanismen her, je nachdem, welche Plattform Sie für das Agent-Hosting verwenden:

  • Benutzerdefinierte Agents in Vertex AI Agent Engine: Private Service Connect-Schnittstellen verbinden die Runtimes von Vertex AI Agent Engine mit dem VPC-Netzwerk. Sie erstellen eine Netzwerkverbindung in einem Subnetz Ihres VPC-Netzwerk und erteilen Vertex AI Agent Engine die Berechtigung, eine Verbindung dazu herzustellen. Traffic, der von Vertex AI Agent Engine gesendet wird, wird im VPC-Netzwerk so angezeigt, als ob er von der Subnetz-IP-Adresse der Anlage stammt. Das VPC-Netzwerk leitet den Traffic dann an die entsprechende Ziel-IP-Adresse weiter.
  • Benutzerdefinierte Agents in Cloud Run: Mit dem ausgehenden Direct VPC-Traffic von Cloud Run werden die Cloud Run-Dienstinstanzen mit dem VPC-Netzwerk verbunden. Das VPC-Netzwerk, das beim Bereitstellen 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 Direct VPC-Ausgangs 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 jede Agent-Hosting-Plattform. Die Netzwerküberlegungen gelten sowohl für die Funktionen des Root-Agents als auch für die des Sub-Agents.

Netzwerk für Vertex AI Agent Engine

In diesem Abschnitt wird die private Vernetzung für Root- und Subagenten beschrieben, die in der Vertex AI Agent Engine gehostet werden. Wenn Sie Vertex AI Agent Engine zum Hosten Ihres Stamm-Agents verwenden, müssen Sie Gemini Enterprise und Vertex AI Agent Engine im selben Projekt bereitstellen.

In Vertex AI Agent Engine werden Container in der Google-Infrastruktur außerhalb Ihres VPC-Netzwerk gehostet. Wenn Sie eine private Verbindung zu anderen Agents herstellen möchten, können Sie Ihren Agent mit Ihrem VPC-Netzwerk verbinden. Dazu haben Sie folgende Möglichkeiten:

Wenn Sie Anfragen zwischen Ihren und anderen Agenten zulassen möchten, müssen Sie beide oben genannten Verbindungen einrichten.

Ausgehender Traffic von Vertex AI Agent Engine zum VPC-Netzwerk

Vertex AI Agent Engine verwendet ein von Google verwaltetes Mandantenprojekt für den Netzwerkausgang. Das Mandantennetzwerk bietet Konnektivität für Agents zu Google-APIs und für ausgehenden Traffic über das öffentliche Internet, ist aber standardmäßig nicht direkt mit den VPC-Netzwerken des Kunden verbunden.

Um Agents mit Ressourcen in Ihrem VPC-Netzwerk zu verbinden, verwendet Vertex AI Agent Engine Private Service Connect-Schnittstellen. Vertex AI Agent Engine stellt eine Netzwerkschnittstelle im Mandantenprojekt bereit, die eine Verbindung zu einer Netzwerk-Attachment-Ressource in Ihrem Projekt herstellt. Durch diese Verbindung wird ein sicherer Datenpfad zwischen der Vertex AI Agent Engine-Laufzeit und dem VPC-Netzwerk erstellt. Wenn Sie eine Private Service Connect-Schnittstelle in Ihrem Vertex AI Agent Engine-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 VPC-Netzwerk-Egress von Vertex AI Agent Engine finden Sie in den folgenden Ressourcen:

Weitere Informationen zum Sichern von Agents und des VPC-Netzwerk für den Egress von Vertex AI Agent Engine finden Sie in den folgenden Abschnitten dieses Dokuments:

Eingehender Traffic aus dem VPC-Netzwerk für Vertex AI Agent Engine

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

Private Nutzer, die Anfragen an Agents stellen, müssen den Hostnamen des Vertex AI API-Endpunkt in den privaten IP-Adressbereich für 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 Vertex AI API auf. Das VPC-Netzwerk leitet die Anfrage direkt über das Google-Produktionsnetzwerk weiter.

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

Zusätzliche Überlegungen zum Netzwerk für Vertex AI Agent Engine

Der ausgehende Traffic von Vertex AI Agent Engine, der Private Service Connect-Schnittstellen verwendet, kann nur an RFC 1918-IP-Adressbereiche im VPC-Netzwerk weitergeleitet werden. Bestimmte Zielbereiche, die nicht über den Egress von Vertex AI Agent Engine geroutet werden können, finden Sie unter Anforderungen an den IP-Adressbereich des Subnetzwerks. Wenn Sie Ziele mit nicht routbaren IP-Adressbereichen erreichen möchten, verwenden Sie eine explizite Proxykonfiguration für die Agents und stellen Sie Proxyressourcen bereit, die eine routbare IP-Adresse im VPC-Netzwerk verwenden.

Wenn die Vertex AI Agent Engine ohne eine Private Service Connect-Schnittstelle bereitgestellt wird, hat sie standardmäßig Zugriff auf das Internet. Um sich vor Daten-Exfiltration zu schützen, deaktivieren Sie den Standardzugriff, indem Sie VPC Service Controls aktivieren.

Wenn die Vertex AI Agent Engine mit einer Private Service Connect-Schnittstelle bereitgestellt wird, ist der direkte Internet-Ausgang unabhängig von VPC Service Controls deaktiviert. Wenn Ihr Agent auf ein Ziel zugreifen muss, das Vertex AI Agent Engine 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 sicheren Web-Proxys.
  3. Konfigurieren Sie DNS-Peering für Vertex AI Agent Engine, um die Auflösung von Agent-DNS-Abfragen an die private Adresse des Secure Web Proxy im VPC-Netzwerk zu unterstützen.
  4. Gehen Sie beim Bereitstellen von Agents so vor:
    1. Definieren Sie Umgebungsvariablen, um den expliziten Proxy zu verwenden. Geben Sie dazu den Hostnamen und Port des Secure Web Proxy an.
    2. Wenn Sie auf ein privates Ziel zugreifen, konfigurieren Sie eine private DNS-Zone für dieses Ziel.

Nachdem der ausgehende Traffic von Vertex AI Agent Engine das VPC-Netzwerk erreicht hat, kann er jedes Netzwerkziel erreichen, das vom VPC-Netzwerk geroutet werden kann. Informationen dazu, wie Sie den Umfang der Egress-Netzwerkziele einschränken, die für Vertex AI Agent Engine-Agents verfügbar sind, finden Sie weiter unten in diesem Dokument im Abschnitt Cloud NGFW.

Cloud Run-Netzwerk

In diesem Abschnitt wird die private Vernetzung für Root-Agents und Sub-Agents beschrieben, die in Cloud Run gehostet werden. Cloud Run hostet Container in der Google-Infrastruktur außerhalb Ihres VPC-Netzwerk. Wenn Sie private Verbindungen zu anderen Agents aktivieren möchten, können Sie Ihren Agent mit Ihrem VPC-Netzwerk verbinden. Dazu haben Sie folgende Möglichkeiten:

Wenn Sie Anfragen zwischen Ihren und anderen Agenten zulassen möchten, müssen Sie beide oben genannten Verbindungen einrichten.

Ausgehender Cloud Run-Traffic zum VPC-Netzwerk

Wenn Sie Cloud Run-Verbindungen in ein VPC-Netzwerk initiieren möchten, empfehlen wir die Verwendung von Direct VPC-Ausgang. Beim ausgehenden Direct VPC-Traffic stellen Cloud Run-Instanzen über eine IP-Adresse aus dem Subnetz, das Sie beim Bereitstellen des ausgehenden Direct VPC-Traffics angeben, eine direkte Verbindung zum freigegebenen VPC-Netzwerk her.

Wenn Sie ausgehenden Direct VPC-Traffic konfigurieren, gehen Sie so vor:

  1. Konfigurieren Sie das Zielsubnetz mit aktiviertem privaten Google-Zugriff.
  2. Konfigurieren Sie Traffic-Routing, um den gesamten Traffic an das VPC-Netzwerk weiterzuleiten.

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

Für alle DNS-Abfragen von Cloud Run werden die Cloud DNS-Richtlinie und -Zonen verwendet, die dem VPC-Netzwerk zugeordnet sind. Es ist keine zusätzliche DNS-Peering-Konfiguration erforderlich. Agents, die auf Cloud Run gehostet werden, 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, in denen KI-Agenten- oder Tool-Arbeitslasten ausgeführt werden. Diese Endpunkte werden vom selben GFE-Einstiegspunkt bereitgestellt, der auch *.googleapis.com-API-Dienste bereitstellt. Cloud Run verwendet dieselben zugrunde liegenden Netzwerkpfade, die private Verbindungen für den privater Google-Zugriff und für Private Service Connect für Google APIs ermöglichen.

Private Nutzer im VPC-Netzwerk, die Anfragen an Agents oder Tools stellen, müssen den Hostnamen run.app in den privaten IP-Adressbereich für 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 Cloud Run-Ingress 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 Endpunkt für ausgehenden Direct VPC-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, der von außerhalb des Cloud Run-Dienstprojekts oder der freigegebene VPC-Umgebung stammt, als extern behandelt. Dazu gehört auch Traffic von anderen Google Cloud-Diensten wie Vertex AI Agent Engine und anderen Cloud Run-Diensten. Damit die Prüfung des internen eingehenden Traffics von Cloud Run erfolgreich ist, muss dieser Traffic so weitergeleitet werden, dass er aus dem VPC-Netzwerk des Zieldienstes zu stammen scheint.

Sie haben folgende Möglichkeiten, die erforderliche Attributierung für interne Netzwerke bereitzustellen:

  • Verwenden Sie Private Service Connect-Endpunkte, damit Dienste in anderen VPCs oder Projekten über eine private IP-Adresse in Ihrem VPC-Netzwerk eine Verbindung zu Google APIs und ‑Diensten, einschließlich Ihres Cloud Run-Dienstes, herstellen können.
  • 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 Ingress-Kriterien erfüllen.

Bei internen Application Load Balancern mit serverlosen NEG-Backends (Network Endpoint Group) wird eine VPC-Ressource erstellt, 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 Sicherheitsfunktionen, darunter Backend-Sicherheitsrichtlinien von Cloud Armor und zusätzliche Autorisierungsrichtlinien.

Standardmäßig erfordert der Zugriff auf alle Cloud Run-Dienste die IAM-Authentifizierung. Wir empfehlen, eine Identität pro Dienst zu verwenden und dem Prinzipal die IAM-Rolle „Cloud Run-Aufrufer“ (roles/run.invoker) zuzuweisen.

Informationen zum Konfigurieren von Cloud Run-Ingress-Steuerelementen 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 Funktionen schützen:

GKE-Netzwerk

In diesem Abschnitt wird die Vernetzung für Agents beschrieben, die auf GKE basieren.

GKE und Gemini Enterprise

Als Host für KI-Agents und ‑Tools bietet GKE eine hochgradig anpassbare Plattform für Netzwerk- und Sicherheitskontrollen. Ein Multi-Agenten-KI-System, das in GKE bereitgestellt wird, kann für operative Effizienz in großem Maßstab sorgen. Sie lässt sich eng in andere Kubernetes-Apps und größere Microservices-Architekturen 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 Agents aufrufen können, die auf GKE gehostet werden, müssen Sie ein externes Gateway mit einer öffentlichen IP-Adresse und einem DNS-Namen sicher bereitstellen. Der Traffic fließt von Gemini Enterprise als ausgehender 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 schützen. Um ein umfassendes Defense-in-Depth-Modell zum Sichern von KI-Agents bereitzustellen, die in GKE ausgeführt werden, sollten Sie die Sicherheitskontrollen berücksichtigen, die in den folgenden Abschnitten beschrieben werden.

GKE-Betriebsmodus

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

  • Autopilot: Google automatisiert die gesamte GKE-Clusterinfrastruktur, einschließlich der Steuerungsebene, der Knotenbereitstellung, der Sicherheitsoptimierung und der Skalierung.
  • Standard: Google verwaltet die Steuerungsebene. Sie behalten die volle Verantwortung für Knotenpoolkonfigurationen, z. B. für die Auswahl von Maschinentypen, die Verwaltung von Betriebssystem-Images und die manuelle Skalierung.
Härten der Infrastruktur und der Steuerungsebene
  • Private GKE-Cluster: Stellen Sie Knoten ohne öffentliche IP-Adressen bereit, um sicherzustellen, dass die Laufzeitumgebung vor direkter Internetexposition geschützt ist.
  • Autorisierte Masternetzwerke: Beschränken Sie den administrativen Zugriff auf die Kubernetes API auf bestimmte, vertrauenswürdige IP-Adressbereiche. Dadurch wird die Steuerungsebene vor unautorisierten 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 Traffic-Management
  • Cloud Armor: Bietet robuste Edge-Sicherheit, einschließlich WAF-Regeln (Web Application Firewall), um schädliche Nutzlasten zu blockieren, DDoS-Schutz, um die Betriebszeit zu gewährleisten, und Ratenbegrenzung, um die Erschöpfung von Diensten zu verhindern.
  • Model Armor: Model Armor wurde speziell für die Sicherheit von LLMs 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 dem geringsten Berechtigungsprinzip zwischen Mikrodiensten. Standardmäßig wird in Richtlinien der gesamte Traffic abgelehnt, sofern Sie ihn nicht explizit zulassen. Dadurch wird die laterale Bewegung 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. Er 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 im VPC-Netzwerk des Clusters und in anderen verbundenen VPC-Netzwerken nativ routingfähig.

Wenn ein Agent-Pod mit einem Subagent-Pod auf demselben Knoten kommuniziert, wird der Traffic lokal innerhalb des Knotennetzwerk-Namespace weitergeleitet. Wenn sich der Ziel-Agent-Pod auf einem anderen Knoten im Cluster befindet, wird der Traffic über die Routingtabelle des VPC-Netzwerk 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 standardmäßige VPC-Routing erreichen, sofern die Firewallregeln dies zulassen.

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

GKE-Eingang aus dem VPC-Netzwerk

Kubernetes-Services bieten Zugriff auf GKE-Ressourcen. Für ein KI-System mit mehreren Agents empfehlen wir die Verwendung eines GKE-Gateways oder eines GKE Inference Gateways. Das Gateway bietet erweiterte Funktionen für die Traffic-Steuerung, die betriebliche Trennung von Ressourcen und Sicherheitsintegrationen. Je nach Ihren Systemanforderungen sind jedoch auch andere Ingress-Dienstoptionen verfügbar.

Durch die Gateway-Ressource wird ein Application Load Balancer erstellt und alle erforderlichen Load-Balancing-Komponenten werden bereitgestellt. Die Backend-Netzwerk-Endpunktgruppen des Dienstes sind so konfiguriert, dass das Load-Balancing direkt für Container erfolgt. 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-Agents und ‑Tools, die auf GKE-Clustern gehostet werden:

  • Cloud Armor: Schützt Dienste, indem eine Cloud Armor-Sicherheitsrichtlinie an die Back-End-Dienste angehängt wird, die vom Gateway verwaltet werden. Es bietet WAF-Screening, IP-Adress- und standortbasiertes Filtern, DDoS-Schutz und Ratenbegrenzung, bevor Traffic den GKE-Cluster oder IAP erreicht.
  • IAP: Auf dem Backend-Dienst aktiviert, um den Zugriff auf Apps 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. Anrufer müssen eine Identität haben, die von IAM authentifiziert wird, und die Berechtigung zum 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 Funktionen 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.

Sicherheit des Agent-Netzwerks

Um das Netzwerk eines KI-Systems mit mehreren Agents zu schützen, müssen Sie die Kommunikation sowohl über das VPC-Netzwerk als auch über die API-Oberfläche sichern. Die Datenebene des VPC-Netzwerk beschreibt, wie Agents und Tools sicher verbunden werden. Die API-Oberfläche definiert, welche Identitäten und Arten von Datenaustausch zulässig sind. Durch die Staffelung der Zugriffssteuerungen sowohl im VPC-Netzwerk als auch in der API-Oberfläche wird ein hochgradig kontrollierter und robuster Sicherheitsstatus erzwungen.

Cloud NGFW

Cloud NGFW fungiert als Gatekeeper auf Netzwerkebene, um die Kommunikation zwischen Apps und MCPs zu schützen. Die Firewall sorgt dafür, dass nur autorisierter Traffic die Agent-Endpunkte erreichen kann. Dazu wird jede eingehende oder ausgehende Verbindung zu und von anderen Agenten und Tools überprüft.

Cloud NGFW ist ein verteilter Firewall-Dienst, der in das VPC-Netzwerk integriert ist. Es bietet die folgenden Funktionsstufen, die auf verschiedenen Ebenen des Netzwerkstacks ausgeführt werden:

  • 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 Durchsetzung mit FQDN-Objekten (voll qualifizierter Domainname), Standortobjekten und Feeds von Google Threat Intelligence, um bekannte schädliche Adressen zu blockieren.
  • Cloud Next Generation Firewall Enterprise: Bietet echte App-Prüfungsfunktionen (L7) mit TLS-Entschlüsselung und IDPS-Funktionen (Intrusion Detection and Prevention System), um Nutzlasten anhand erweiterter Bedrohungssignaturen zu analysieren.

Cloud NGFW kann auf das VPC-Netzwerk angewendet werden, um die Firewallrichtlinie basierend auf den Regeln zu erzwingen, die für die Zielplattform für das Agent-Hosting erforderlich sind.

  • Vertex AI Agent Engine: Agents, die in Vertex AI Agent Engine 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 Traffic basierend auf den Quell-IP-Adressen aus dem Subnetz, das dem Private Service Connect-Netzwerkanhang zugewiesen ist. Für den Traffic-Abgleich können Sie Quell- und Ziel-IP-Adressbereiche verwenden.
  • Cloud Run: Cloud Run-Dienste, die Direct VPC-Ausgang 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-Adressbereiche 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 auf Knoten mit bestimmten Tags ausgerichtet sein oder Traffic von solchen Knoten beziehen. Firewallregeln können auch auf GKE-Knoten ausgerichtet sein oder Traffic von GKE-Knoten basierend auf der Dienstkontoidentität des Knotenpools als Quelle verwenden.

Standardrichtlinie zum Ablehnen von ausgehendem Traffic

Die Implementierung einer Standardablehnungsstrategie 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 Flows und einer DENY-Regel mit niedriger Priorität erreicht. In allen Cloud NGFW-Stufen sind Regeln basierend auf Quell- und Ziel-IP-Adressbereichen zulässig.

Firewallrichtlinienregeln können Quell-Traffic aus dem Subnetz der Netzwerkverbindung der Vertex AI Agent Engine und aus dem Subnetz für direkten VPC-Ausgang von Cloud Run effektiv abgleichen.

Das folgende Beispiel zeigt eine Standardrichtlinie für ausgehenden Traffic, die den Zugriff standardmäßig verweigert:

  • 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) basierend auf den Quell-IP-Adressbereichen (--src-ip-ranges=SRC_IP_RANGES) und den Ziel-IP-Adressbereichen (--dest-ip-ranges=DEST_IP_RANGES) ausgerichtet sind.
  • 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 mit dem Quell-Traffic aus dem Subnetz des Netzwerk-Attachments der Vertex AI Agent Engine oder aus dem Subnetz des Direct VPC Egress von Cloud Run übereinstimmt.
  • Allgemeine DENY-Regel: Damit die Regel als Letztes ausgewertet wird, verwenden Sie die höchste Prioritätsnummer, z. B. 2147483647. Mit dieser Regel wird der Traffic zu allen Zielen (--dest-ip-ranges=0.0.0.0/0) abgelehnt, der keiner der vorangehenden ALLOW-Regeln entspricht.

Eine Standardablehnungsrichtlinie für ausgehenden Traffic verhindert, dass KI-Agents Netzwerkverbindungen herstellen, die nicht explizit autorisiert sind. Außerdem wird so das Risiko von Datenexfiltration oder Zugriff auf schädliche Websites verringert. Die Richtlinie beschränkt die Kommunikation der gehosteten Agents auf genehmigte Endpunkte. Das ist entscheidend, um die Kontrolle über autonome Arbeitslasten zu behalten.

Zusätzliche Hinweise zu Cloud NGFW-Richtlinien

Zusätzlich zur Standardstrategie „Standardmäßig ablehnen“, die in allen Cloud NGFW-Stufen verfügbar ist, können Sie die Netzwerksicherheit Ihrer Multi-Agenten-KI mit Funktionen der kostenpflichtigen Stufen weiter erhöhen:

  • Cloud NGFW Standard-Funktionen:
    • FQDN-Objekte für dynamische Endpunkte: KI-Agents 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 über den Domainnamen zu ermöglichen.
    • Standortkontrollen: Wenn für KI-Agents 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 Egress-Filtern, um automatisch zu verhindern, dass Agents eine Verbindung zu bekannten schädlichen Zielen wie Command-and-Control-Servern (C2), Anonymisierungstools wie Tor und Malware-Verteilungswebsites herstellen. Die Verwendung von Google Threat Intelligence trägt dazu bei, die Auswirkungen eines potenziell kompromittierten Agents einzudämmen. Wir empfehlen, diese Zielfilter in die DENY-Regeln mit der höheren Prioritätsnummer (niedrigere Auswertungsreihenfolge) aufzunehmen.
  • Cloud NGFW Enterprise-Funktionen:
    • Prüfung auf Schicht 7: Bei Agents, die vertrauliche Daten verarbeiten oder einem höheren Risiko ausgesetzt sind, sollten Sie die Paketnutzlasten auf Bedrohungen wie Malware, Spyware und Exploits prüfen, die nicht durch Firewallregeln auf der 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 von entscheidender Bedeutung, da die meisten modernen Angriffe und C2-Kommunikation verschlüsselt sind.

Weitere Implementierungshinweise oder Einschränkungen, die möglicherweise für Ihre Umgebung gelten, finden Sie in den folgenden Ressourcen:

IAP

IAP sichert Ingress-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 die Berechtigungen des Aufrufers. IAP lässt nur authentifizierte und autorisierte Anfragen an die Arbeitslast des Backend-Dienstes weiterleiten. 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 auf GKE gehostet und durch IAP geschützt sind, muss den Identitäten der Prinzipale die IAM-Rolle „Nutzer von IAP-gesicherten Web-Apps“ (roles/iap.httpsResourceAccessor) für die IAP-geschützte Backend-Dienstressource zugewiesen werden. Wir empfehlen, ein benutzerdefiniertes Dienstkonto als Identität für bereitgestellte Agents zu konfigurieren. Wenn Sie ein benutzerdefiniertes Dienstkonto verwenden, können Sie Berechtigungen genauer nach dem Prinzip der geringsten Berechtigung zuweisen.

Gewähren Sie die IAM-Rolle „Nutzer von IAP-gesicherten Web-Apps“ nur direkt den Dienstkonten von Agents, die auf andere Agents und Tools zugreifen dürfen, die in der benutzerdefinierten GKE-Ressource BackendConfig gehostet werden. Wenn Sie den Zugriff auf Gemini Enterprise-Apps zulassen möchten, gewähren Sie Berechtigungen, indem Sie die IAM-Rolle Discovery Engine-Dienstkonto (roles/discoveryengine.serviceAgent) für Ihr Gemini Enterprise-Projekt binden.

VPC Service Controls

VPC Service Controls verringert das Risiko einer Daten-Exfiltration durch die strenge Kontrolle des Zugriffs auf Google APIs. Wir empfehlen, einen einzelnen Makroperimeter bereitzustellen, der alle unterstützten Dienste umfasst. Dieser Ansatz bietet den besten Schutz vor Exfiltration. Damit die Richtlinien für Architekturen mit gemeinsam genutzter VPC einheitlich durchgesetzt werden, müssen sowohl das Hostprojekt als auch alle zugehörigen Dienstprojekte im selben Dienstperimeter enthalten sein.

Um die Interaktion zwischen Gemini Enterprise und Cloud Run über Projektgrenzen hinweg zu schützen, sollten Sie die folgenden Empfehlungen berücksichtigen:

  • Stellen Sie einen einzelnen VPC Service Controls-Perimeter bereit, der sowohl das Gemini Enterprise- als auch das Cloud Run-Projekt umfasst.
  • Fügen Sie der Liste der eingeschränkten Dienste alle unterstützten VPC Service Controls-Dienste hinzu. So können Sie nicht autorisierte administrative Änderungen verhindern.
  • Erzwingen Sie interne Ingress- und Autorisierungseinstellungen, 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 Invoker (roles/run.invoker) für den Zieldienst haben. Die Rolle wird geprüft, indem ein Token aus dem Autorisierungsheader validiert wird. Damit der Cloud Run-Dienst erfolgreich aufgerufen werden kann, muss Dienstkonten, z. B. denen, 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 Traffic von Cloud Run auf „Intern“ zu setzen. Ohne diesen Perimeter werden projektübergreifende Aufrufe von Gemini als externer Traffic behandelt. Das zwingt Sie, den Cloud Run-Eingang auf „Alle“ festzulegen, wodurch der Dienst dem öffentlichen Internet ausgesetzt ist.

  • Cloud Run-Ingress 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 Cloud Run-Ingress internal unterstützt.

Zusätzliche Überlegungen zu VPC Service Controls

Wenn Cloud Run in einem VPC Service Controls-Perimeter 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:run.allowedIngress-Einschränkung als Organisationsrichtlinie festlegen, um zu verhindern, dass Entwickler versehentlich öffentlich zugängliche Endpunkte bereitstellen. 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.
  • Einstellungen für ausgehenden VPC-Traffic einschränken: Damit alle ausgehenden Anfragen über die VPC weitergeleitet werden, sodass sie von Perimeter-Firewallregeln geprüft werden können, legen Sie den Wert der Organisationsrichtlinie run.allowedVPCEgress auf all-traffic fest. Bei dieser Einstellung muss für jede Cloud Run-Revision ausgehender Direct VPC-Traffic oder ein Connector für Serverloser VPC-Zugriff verwendet werden. 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 nicht den erforderlichen Einstellungen für eingehenden und ausgehenden Traffic entsprechen, neu bereitzustellen oder zu aktualisieren.
  • Container-Images und ‑Dienste zusammenstellen: Das Artifact Registry-Repository, das Ihre Container-Images enthält, muss sich im selben Perimeter wie der Cloud Run-Dienst befinden. Das Abrufen von Images über die Perimetergrenze hinweg wird automatisch blockiert, sofern Sie keine expliziten Regeln für eingehenden und ausgehenden Traffic einrichten.
  • Zugriffsebenen verwalten: Regeln von VPC Service Controls-Richtlinien für eingehenden Traffic und Zugriffsebenen, die auf IAM-Hauptkontenidentitä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 erweiterte Sicherheitsfunktionen für KI-Apps bietet. KI-Agents interagieren mit Model Armor, indem sie Aufrufe ausführen, 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 überprüft LLM-Prompts und ‑Antworten aktiv. Das ist ein wichtiger Prüfpunkt, um neue Risiken zu erkennen und verantwortungsbewusste KI-Standards zu implementieren. Wir empfehlen, Model Armor zu verwenden, um die Anforderungen an den Datenspeicherort und die rechtlichen Bestimmungen zur Datenhoheit einzuhalten. Wenn Sie Model Armor in einer VPC Service Controls-Umgebung 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 tragen dazu bei, dass die Anforderungen hinsichtlich des Datenstandorts erfüllt werden.

Um den Zugriff für Agents zu aktivieren, 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 regionalen Endpunkt-Hostname von Model Armor (z. B. modelarmor.us-central1.rep.googleapis.com), der in die IP-Adresse des regionalen Endpunkts aufgelöst wird.
  4. Für die Interoperabilität von Vertex AI Agent Engine müssen Sie DNS-Peering von Vertex AI Agent Engine zur privaten Cloud DNS-Zone einrichten, die mit Ihrem VPC-Netzwerk verknüpft ist. Wenn Agents 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 Agents, 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 des Backend-Dienstes erreichen. KI-Agent-Arbeitslasten umfassen ein hohes Volumen an dienstübergreifender Kommunikation, bei der A2A-, MCP- und API-Aufrufe verwendet werden. Der Cloud Armor-Schutz bietet zusätzliche Resilienzebenen im Sicherheitskonzept mit Ratenbegrenzung, WAF-Screening und benutzerdefinierten Regeln, die den erwarteten agentenbasierten Anfragen entsprechen. Wenn Sie Cloud Armor-Sicherheitsrichtlinien an Application Load Balancer-Back-End-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 einer Agent-Netzwerkarchitektur in den folgenden Szenarien bereitgestellt werden:

  • Cloud Run mit internem Application Load Balancer: Schützen Sie Agents und Tools, die in Cloud Run ausgeführt werden, mit einem internen Application Load Balancer mit serverlosen NEG-Backends. Wenden Sie Backend-Sicherheitsrichtlinien auf die serverlose NEG an, um WAF-Regeln für internen Traffic und Ratenbegrenzung zu erzwingen. Um die Kommunikation mit dem Agent zu steuern, können Sie zusätzliche benutzerdefinierte Regeln basierend auf IP-Adressen und Headern definieren.
  • Gateway: Schützen Sie Agents 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-Back-Ends verwenden. Verwenden Sie die Kubernetes Gateway API, um die GCPBackendPolicy-Ressource 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-Adress- und geografischen Kontrollen sowie Ratenbegrenzung. Globale externe Application Load Balancer unterstützen Back-End-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. Sie fungiert als zentraler Proxy und Sicherheitskontrollpunkt, um eine detaillierte Steuerung und Übersicht für ausgehenden Internettraffic zu ermöglichen. Es dient auch als expliziter Proxy für die interne Dienstkommunikation.

Secure Web Proxy unterstützt drei Bereitstellungsmodi: den Modus für explizites Proxy-Routing, den Modus für Private Service Connect-Dienstanhänge und den Next-Hop-Modus. Wir empfehlen, Secure Web Proxy im Modus für explizites Proxy-Routing 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 für die spezifische Integration mit der Proxyressource bereitgestellt und konfiguriert. Diese Konfiguration schreibt vor, dass alle ausgehenden Anfragen den Secure Web Proxy durchlaufen müssen, bevor sie ins Internet gelangen.

Die Verwendung von Secure Web Proxy als expliziter Proxy unterstützt Agent-Anfragen, die von Vertex AI Agent Engine Private Service Connect-Schnittstellen, Cloud Run Direct VPC-Ausgang 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 ihn an den kontrollierten Internet-Ausgang oder an private Netzwerkziele, die über das VPC-Netzwerk geroutet werden können.

Explizites Proxy-Routing

Für den ausgehenden Traffic von Vertex AI Agent Engine ist eine explizite Proxykonfiguration erforderlich, damit Agents Internetziele oder nicht routbare IP-Adressbereiche im VPC-Netzwerk erreichen können. Für die Interoperabilität mit Vertex AI Agent Engine 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 Vertex AI Agent Engine erreichbar. Anschließend kann sie alle Verbindungen zu nicht routingfähigen IP-Adressenzielen, die sich im VPC-Netzwerk oder in verbundenen Netzwerken befinden, per Proxy weiterleiten.

Damit Agent-Hosting-Plattformen Secure Web Proxy im expliziten Routingmodus verwenden können, müssen Sie die folgenden Netzwerkressourcen konfigurieren:

  1. Erstellen oder identifizieren Sie ein RFC 1918-Subnetz im VPC-Netzwerk, in dem die Secure Web Proxy-Ressource gehostet werden soll.
  2. Erstellen Sie einen Cloud DNS-Eintrag für den Secure Web Proxy-Hostname (z. B. swp.example.com), der in die IP-Adresse der Secure Web Proxy-Ressource aufgelöst wird.
  3. Für die Interoperabilität von Vertex AI Agent Engine müssen Sie DNS-Peering von Vertex AI Agent Engine zur privaten Cloud DNS-Zone einrichten, die mit Ihrem VPC-Netzwerk verknüpft ist. Wenn Agents Anfragen an den sicheren Webproxy senden, löst Cloud DNS die Hostnamenanfragen in die IP-Adresse der sicheren Webproxy-Ressource im VPC-Netzwerk auf. Dieser Schritt ist für Agents, die in Cloud Run und GKE gehostet werden, nicht erforderlich.

Proxy-Einstellungen für Agenten

Die Standardmethode zum Konfigurieren von Agent-Apps 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-CONNECT-Methode vom Client zum Proxy verwendet. Obwohl HTTP angegeben ist, wird die TLS-Verschlüsselung durch den Proxy von der Agent-Laufzeit bis zum Zielendpunkt durchgehend aufrechterhalten.
  • HTTPS_PROXY: Die URL des expliziten Proxyservers für HTTPS-Traffic (z. B. https://swp.example.com:8888). Wie bei der Einstellung HTTP_PROXY wird bei der Einstellung HTTPS_PROXY standardmäßig TLS verwendet. Sie können jedoch eine zusätzliche Verschlüsselungsebene bereitstellen, indem Sie Ihre eigene TLS-Verschlüsselung zusätzlich zur Standard-TLS 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 der Liste NO_PROXY hinzufügen, können Arbeitslasten direkt auf den Metadatendienst zugreifen, um sich für Google-APIs und -Dienste zu authentifizieren und zu autorisieren.

Wenn Sie das Argument env_vars verwenden, um Variablen während der Bereitstellung festzulegen, sind sie in der Agent-Laufzeitumgebung verfügbar (z. B. wenn Sie os.environ in Python verwenden). Die meisten Standard-HTTP-Clientbibliotheken erkennen und verwenden diese Umgebungsvariablen automatisch, um den Traffic über den angegebenen Proxy weiterzuleiten. Diese Methode ist für Python-Apps 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 Zieldomänen auch in Cloud DNS enthalten sind.

Das folgende Beispiel zeigt die Bereitstellung eines Vertex AI Agent Engine-Proxys über ein Agent-Objekt:

## 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 = aiplatform.agent_engines.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 Dienstversions-Ebene. Mit diesem Ansatz werden alle Umgebungsvariablen mit demselben Namen überschrieben, die im Container-Image festgelegt wurden. Dieser Ansatz ist nützlich, um Betriebsparameter wie Proxyvariablen festzulegen, wenn die Dienstinstanzen gestartet werden.

Das folgende Beispiel zeigt den Befehl zum Festlegen der Umgebungsvariablen beim Bereitstellen eines Cloud Run-Dienstes:

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 Proxykonfiguration in GKE-Pods implementieren möchten, definieren Sie eine ConfigMap-Ressource, in der die Proxyvariablen angegeben werden:

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 Containermanifest. Durch diese 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 für das Ziel einer Arbeitslast TLS verwendet wird, erstellt und signiert die Zertifizierungsstelle 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 es 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 CA Service konfiguriert wurde, wird die Signierung von untergeordneten Zertifikaten bis zum Ablauf des Root-CA-Zertifikats übernommen. Root-CA-Zertifikate müssen aktualisiert werden, damit sie nicht ablaufen.

CA Service unterstützt die folgenden Funktionen, um die Überprüfung des Traffics und die Zertifikatsverwaltung in großem Maßstab in einer KI-Architektur mit mehreren Agenten zu ermöglichen:

  • TLS-Prüfung: Für die vollständige TLS-Prüfung ist die Verwendung einer privaten CA erforderlich. Damit HTTPS-Nutzlasten vollständig entschlüsselt und analysiert werden können, muss das zwischengeschaltete Proxygerät (Secure Web Proxy oder Cloud NGFW) die TLS-Sitzung mit dem Client beenden. Der Proxy muss ein gültiges Zertifikat präsentieren, das der Client für die angeforderte Domain als vertrauenswürdig akzeptiert.

    Der CA-Dienst kann dynamisch ein standortspezifisches Identitätsdiebstahlzertifikat 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.

  • Zertifikatverteilung: Interne Clientressourcen wie KI-Agents, die in Vertex AI Agent Engine, Cloud Run oder GKE ausgeführt werden, benötigen das private Stamm-CA-Zertifikat, das ihren lokalen Trust Stores hinzugefügt wird. Wenn Sie den öffentlichen Schlüssel des Root-CA-Zertifikats in Secret Manager speichern, können KI-Agents das Zertifikat beim Start abrufen und ihrem System-Truststore hinzufügen.

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

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

A2A-Verbindungssicherheit

Root-Agents kommunizieren mit einer Vielzahl von Sub-Agents und MCP-Servern, die auf verschiedenen Laufzeit-Hostingplattformen bereitgestellt werden. Jede Umgebung stellt 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 dieser Designanleitung unterstützt werden:

Agent2Agent-Verbindungsmuster (A2A) zwischen verschiedenen Hostingplattformen wie GKE, Cloud Run und Vertex AI Agent Engine sowie Verbindungen zu MCP-Servern und dem Internet.

Das obige Diagramm fasst diese Verbindungsmöglichkeiten zusammen:

  • Nutzer interagieren über eine Gemini Enterprise-App mit dem Agent-System.
  • Die Gemini Enterprise-App verwendet die Google-Infrastruktur, um eine Verbindung zu einem Root-Agent herzustellen, der in GKE, Cloud Run oder Vertex AI Agent Engine ausgeführt wird.
  • Die Gemini Enterprise-App und die Stamm-Agents verwenden die Google-Infrastruktur, um eine Verbindung zu Model Armor und dem Gemini-LLM in Vertex AI herzustellen.
  • Die Stamm-Agents können die Google-Infrastruktur verwenden, um eine Verbindung zu untergeordneten Agents herzustellen, die in Cloud Run oder Vertex AI Agent Engine ausgeführt werden.
  • Die Stamm-Agents können private IP-Adressen verwenden, um eine Verbindung zu untergeordneten Agents herzustellen, die in Vertex AI Agent Engine, Cloud Run und GKE ausgeführt werden. Diese Verbindungen müssen über ein VPC-Netzwerk weitergeleitet werden.
  • Sowohl Root- als auch Sub-Agents können eine Verbindung zu MCP-Servern herstellen, die in Cloud Run oder GKE ausgeführt werden. Für die Verbindung von Agenten mit den MCP-Servern kann entweder die Google-Infrastruktur oder ein VPC-Netzwerk verwendet werden. Die MCP-Server bieten Zugriff auf Tools, die inGoogle Cloud, lokal, in einer anderen Cloud oder im Internet gehostet werden.
  • Auf Dienste, die im Internet gehostet werden, kann direkt über Secure Web Proxy zugegriffen 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 Verbindungen und die Implementierung der mehrschichtigen Sicherheitsmaßnahmen, die zum Schutz des End-to-End-Datenpfads zwischen Agents erforderlich sind.

GKE-Quell-Agent

Die folgende Tabelle enthält Ressourcen, die Ihnen helfen, Traffic zu schützen, wenn GKE der Quell-Agent ist. Dieser Traffic wird über das VPC-Netzwerk geleitet, in dem sich der GKE-Cluster befindet.

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

Vertex AI Agent Engine-Quellagent (intern)

Die folgende Tabelle enthält Ressourcen, mit denen Sie den Traffic schützen können, wenn Vertex AI Agent Engine der Quell-Agent ist und der Traffic direkt über die Google-Infrastruktur übertragen wird. Bei diesen Pfaden ist kein VPC-Netzwerk beteiligt.

Ziel-Agent (Datenpfad) Sicherheitskontrollen
Vertex AI Agent Engine (intern)
Cloud Run (intern)

Quell-Agent für Vertex AI Agent Engine (Private Service Connect-Schnittstelle)

Die folgende Tabelle enthält Ressourcen, die Ihnen helfen, Traffic zu schützen, wenn Vertex AI Agent Engine der Quell-Agent ist und der Traffic eine Private Service Connect-Schnittstelle verwendet, um durch ein VPC-Netzwerk zu gelangen.

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

Cloud Run-Quell-Agent (intern)

Die folgende Tabelle enthält Ressourcen, die Ihnen helfen, Traffic zu schützen, wenn Cloud Run der Quell-Agent ist und der Traffic direkt über die Google-Infrastruktur übertragen wird. Bei diesen Pfaden ist kein VPC-Netzwerk beteiligt.

Ziel-Agent (Datenpfad) Sicherheitskontrollen
Vertex AI Agent Engine (intern)
Cloud Run (intern)

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

Die folgende Tabelle enthält Ressourcen, die Ihnen helfen, Traffic zu schützen, 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
Private Service Connect für Google APIs für Vertex AI Agent Engine

MCP-Verbindungssicherheit

In der folgenden Liste sind die Hostingplattformen und Defense-in-Depth-Steuerelemente aufgeführt, die zum Sichern des Datenpfads zwischen Agent-Runtimes und MCP-Servern verwendet werden. Verwenden Sie für Quell-Agents in Vertex AI Agent Engine, in Cloud Run oder in 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: