Traffic der Laufzeit für KI-Agenten über das Agent Gateway weiterleiten

Auf dieser Seite wird beschrieben, wie Sie den Traffic der Agent Runtime über das Agent Gateway leiten. Das Agent Gateway ist eine zentrale Netzwerk- und Sicherheitskomponente des Gemini Enterprise Agent Platform-Ökosystems. Es bietet sichere und verwaltete Verbindungen für alle agentischen Interaktionen, unabhängig davon, ob sie zwischen Nutzern und Agents, Agents und Tools oder zwischen Agents selbst stattfinden.

Hinweis

  • Sie müssen mit der Bere0}reitstellung von Agents in der Agent Runtime vertraut sein.

  • Weitere Informationen zum Agent Gateway. Sie können das Agent Gateway im Modus „Agent zu beliebigem Ziel (ausgehend)“ verwenden, um die gesamte ausgehende Kommunikation mit ausgehendem Traffic zu Tools, Modellen, APIs und anderen Agents zu sichern und zu verwalten. Im Modus „Client zu Agent (eingehend)“ können Sie mit dem Gateway steuern, welche Clients auf Ihre Agents zugreifen können. Mit dem Gateway können Sie auswählen, welche IAP-Richtlinien und Model Armor-Vorlagen auf diese Interaktionen angewendet werden müssen.

    Eine einzelne Runtime-Instanz kann gleichzeitig an ein Gateway für „Agent zu beliebigem Ziel (ausgehend)“ und ein Gateway für „Client zu Agent (eingehend)“ gebunden werden.

Beschränkungen

  • Ein Agent Gateway kann nicht an Runtime Reasoning Engines gebunden werden, die vor dem 29. April 2026 erstellt wurden.
  • In einem einzelnen Projekt und einer einzelnen Region können zwar mehrere Agent Gateway-Instanzen für „Agent zu beliebigem Ziel (ausgehend)“ und „Client zu Agent (eingehend)“ gehostet werden, aber alle in diesem Projekt und in dieser Region bereitgestellten Agent Runtime-Agents müssen an dieselben spezifischen Agent Gateway-Instanzen für ausgehenden und eingehenden Traffic gebunden werden.

    Wenn ein Projekt und eine Region beispielsweise egress-gateway-X und egress-gateway-Y enthalten, müssen alle Agents in diesem Projekt und in dieser Region so konfiguriert sein, dass sie dasselbe Gateway für ausgehenden Traffic verwenden. Das heißt, entweder verwenden alle Agents egress-gateway-X oder alle Agents verwenden egress-gateway-Y. Sie können agent-A nicht so konfigurieren, dass er egress-gateway-X verwendet, und agent-B so, dass er egress-gateway-Y verwendet.

    Dieselbe Bindungsregel gilt auch für Ingress-Gateways in einem Projekt und einer Region.

  • Der Security Command Center-Dienst zur Bedrohungserkennung für Agent Engine ist nicht verfügbar, wenn das Agent Gateway für einen Agent aktiviert ist.

  • Im Modus „Client zu Agent (eingehend)“ kann das Agent Gateway nur die Methoden query und streamQuery der Agent Runtime verwalten. Um andere nicht unterstützte Methoden (z. B. asyncQuery) zu schützen, können Sie Model Armor-Vorlagen direkt aus Ihrer Anwendung oder Ihrem Agent anwenden. Weitere Informationen finden Sie unter Prompts und Antworten bereinigen oder in diesem Codelab zum Erstellen eines sicheren Agentensystems mit Model Armor.

  • VPC Service Controls werden mit dem Agent Gateway nicht unterstützt.

  • Das Agent Gateway wird für Agent Runtime-Agents, die Revisionen verwenden, nicht unterstützt. Sie können keine versionsbezogenen Funktionen wie die Konfiguration der Trafficaufteilung und Abfragen pro Revision verwenden, wenn ein Agent Gateway an die Konfiguration eines Agent angehängt ist.

Traffic der Agent Runtime über das Agent Gateway leiten

So leiten Sie den Traffic der Agent Runtime über das Agent Gateway:

  1. Erstellen Sie eine Agent Gateway-Ressource und hängen Sie bei Bedarf Autorisierungsrichtlinien an. Sie können ein Gateway entweder im Modus „Agent zu beliebigem Ziel (ausgehend)“ oder „Client zu Agent (eingehend)“ erstellen. Der Agent und das Gateway müssen im selben Projekt und in derselben Region erstellt werden. Eine Anleitung finden Sie unter Set up Agent Gateway.

    Achten Sie darauf, dass das Gateway so konfiguriert ist, dass es den Anforderungen Ihrer Bereitstellung entspricht. Wenn Ihr Agent beispielsweise LLM-Zugriff benötigt, konfigurieren Sie das Gateway so, dass dieser Zugriff zulässig ist, um potenzielle Bereitstellungsfehler in der Agent Runtime zu vermeiden.

  2. Konfigurieren Sie Ihren Agent so, dass der Traffic über das Agent Gateway geleitet wird.

    • Für neue Agents

      Geben Sie die Gateway-Ressource an, während Sie Ihren Agent bereitstellen. Wenn Sie den Agent beispielsweise in der Agent Runtime bereitstellen möchten, verwenden Sie client.agent_engines.create, um das local_agent Objekt zusammen mit optionalen Konfigurationen zu übergeben.

      Wenn Sie mit diesem Agent Gateway-vermittelte Plattformfunktionen wie Model Armor oder Semantic Governance Policies verwenden möchten, legen Sie sowohl agent_gateway_config als auch identity_type=AGENT_IDENTITY im Erstellungsvorgang fest, wie in diesem Beispiel gezeigt. Ohne identity_type=AGENT_IDENTITY wird die effectiveIdentity der Runtime-Instanz auf das Standarddienstkonto von Vertex AI zurückgesetzt und Semantic Governance Policies filtern den Agent stillschweigend aus der Auswahl für die Richtlinienerstellung heraus.

      remote_agent = client.agent_engines.create(
        agent=local_agent,
        config={
            "agent_gateway_config": {
              "agent_to_anywhere_config": {"agent_gateway": projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_TO_ANYWHERE_NAME},
              # "client_to_agent_config": {"agent_gateway": projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_CLIENT_TO_AGENT_NAME}
            },
            "identity_type": types.IdentityType.AGENT_IDENTITY,
            # Other optional configuration ...
            # "requirements": requirements,
            # "gcs_dir_name": gcs_dir_name,
            # https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/runtime/agent-identity#opt-out-caa
            "env_vars": {
              "GOOGLE_API_PREVENT_AGENT_TOKEN_SHARING_FOR_GCP_SERVICES": False,
            }
        },
      )

      Ersetzen Sie AGENT_GATEWAY_TO_ANYWHERE_NAME durch den Namen des Agent Gateway, das Sie im Modus „Agent zu beliebigem Ziel (ausgehend)“ erstellt haben.

      Wenn Sie ein Gateway im Modus „Client zu Agent (eingehend)“ erstellt haben, verwenden Sie stattdessen das Feld client_to_agent_config und ersetzen Sie AGENT_GATEWAY_CLIENT_TO_AGENT_NAME durch den Namen des Agent Gateway, das Sie für eingehenden Traffic erstellt haben.

    • Für vorhandene Agents

      Agent zu beliebigem Ziel

      Verwenden Sie die folgende REST API-Anfrage, um einen vorhandenen Agent mit einem Agent-to-Anywhere-Gateway für ausgehenden Traffic zu verknüpfen.

      curl -X PATCH \
      -H "Authorization: Bearer $(gcloud auth print-access-token)" \
      -H "Content-Type: application/json; charset=utf-8" \
      -d '{
        "spec": {
          "deploymentSpec": {
            "agentGatewayConfig": {
              "agentToAnywhereConfig": {
                "agentGateway": "projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_TO_ANYWHERE_NAME"
              }
            }
          }
        }
      }' \
      "https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID?updateMask=spec.deploymentSpec.agentGatewayConfig"

      Ersetzen Sie Folgendes:

      • PROJECT_ID: die Projekt-ID
      • REGION: die Region, in der der Agent bereitgestellt wird
      • AGENT_GATEWAY_TO_ANYWHERE_NAME: der Name des Agent Gateway, das Sie im Modus „Agent zu beliebigem Ziel (ausgehend)“ erstellt haben
      • RESOURCE_ID: die Ressourcen ID des Agent

      Client zu Agent

      Verwenden Sie die folgende REST API-Anfrage, um einen vorhandenen Agent mit einem Agent Gateway für „Client zu Agent“ (eingehend) zu verknüpfen.

      curl -X PATCH \
      -H "Authorization: Bearer $(gcloud auth print-access-token)" \
      -H "Content-Type: application/json; charset=utf-8" \
      -d '{
        "spec": {
          "deploymentSpec": {
            "agentGatewayConfig": {
              "clientToAgentConfig": {
                "agentGateway": "projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_CLIENT_TO_AGENT_NAME"
              }
            }
          }
        }
      }' \
      "https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID?updateMask=spec.deploymentSpec.agentGatewayConfig"

      Ersetzen Sie Folgendes:

      • PROJECT_ID: die Projekt-ID
      • REGION: die Region, in der der Agent bereitgestellt wird
      • AGENT_GATEWAY_CLIENT_TO_AGENT_NAME: der Name des Agent Gateway, das Sie im Modus „Client zu Agent (eingehend)“ erstellt haben
      • RESOURCE_ID: die Ressourcen-ID des Agent
  3. Registrieren Sie sich bei der Agent Registry-Instanz im selben Projekt und in derselben Region wie der Agent und das Gateway.

    gcloud agent-registry services create SERVICE_NAME \
      --project=PROJECT_ID \
      --location=REGION \
      --display-name="DISPLAY_NAME" \
      --endpoint-spec-type=no-spec \
      --interfaces='[{url="https://REGION-aiplatform.mtls.googleapis.com",protocolBinding="jsonrpc"}]' \
      --format="value(registryResource)"
    

    Ersetzen Sie Folgendes:

    • SERVICE_NAME: Der Name, den Sie Ihrer Ressource geben möchten, z. B. allow-aiplatform-region-eu3.
    • PROJECT_ID: Die Projekt-ID.
    • REGION: Die Region der Registry.
    • DISPLAY_NAME: Der für Nutzer lesbare Name des Endpunkts.

    Weitere Informationen finden Sie unter Agent registrieren.

  4. Erstellen Sie eine IAM-Richtlinienbindung für „Agent zu Registry“ für den Agent.

    gcloud iap web add-iam-policy-binding \
      --resource-type=agent-registry \
      --endpoint=ENDPOINT_ID \
      --region=REGION \
      --project=PROJECT_ID \
      --member=MEMBER \
      --role=roles/iap.egressor
    

    Ersetzen Sie Folgendes:

    • ENDPOINT_ID: Die Dienstendpunkt-ID des registrierten Agent. Sie erhalten sie aus der Ausgabe des vorherigen Schritts.
    • MEMBER: Der Agent-Identitätsprinzipal, dem die Rolle zugewiesen werden soll. Das Format ist in der Regel: principal://TRUST_DOMAIN/resources/aiplatform/projects/PROJECT_ID/locations/REGION/reasoningEngines/ENGINE_ID.

  5. An diesem Punkt wird der Agent-Traffic über das Agent Gateway geleitet. Das Agent Gateway verwendet jedoch eine Standardablehnungsrichtlinie. Um bestimmte Funktionen der Agent Platform zu aktivieren, müssen Sie dafür sorgen, dass der Agent mit den folgenden Endpunkten kommunizieren kann:

    • Wenn Cloud Trace aktiviert ist, muss das Agent Gateway Traffic zum Endpunkt https://telemetry.googleapis.com/ zulassen.

      Wenn die Umgebungsvariablen GOOGLE_API_USE_CLIENT_CERTIFICATE und GOOGLE_API_USE_MTLS_ENDPOINT festgelegt sind, muss auch Traffic zu https://telemetry.mtls.googleapis.com/ zugelassen werden.

    • Wenn Cloud Logging aktiviert ist, muss das Agent Gateway Traffic zum Endpunkt https://logging.googleapis.com/ zulassen.

      Wenn die Umgebungsvariablen GOOGLE_API_USE_CLIENT_CERTIFICATE und GOOGLE_API_USE_MTLS_ENDPOINT festgelegt sind, muss auch Traffic zu https://logging.mtls.googleapis.com/ zugelassen werden.

    Wenn Ihre Agents LLMs aufrufen oder Funktionen wie Sitzungen und Memory Bank verwenden, müssen Sie außerdem dafür sorgen, dass die Agents mit den Endpunkten kommunizieren können, die von diesen Diensten verwendet werden. Beispiel:

    • Für Sitzungen: https://REGION-aiplatform.googleapis.com/API_VERSION/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID/sessions
    • Für Memory Bank: https://REGION-aiplatform.googleapis.com/API_VERSION/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID/memories

    Aus Sicherheitsgründen empfehlen wir, nur die spezifischen URIs zu registrieren und auf die Zulassungsliste zu setzen, auf die der Agent zugreift. Da das Gateway Hostnamen direkt abgleicht, müssen Sie alle Varianten registrieren, die das Agent SDK verwendet. Je nach SDK-Version, regionaler Clientkonfiguration oder mTLS-Verwendung kann eine Google API beispielsweise über die folgenden Endpunkthostnamen aufgelöst werden:

    • https://REGION-aiplatform.googleapis.com
    • https://REGION-aiplatform.mtls.googleapis.com
    • https://aiplatform.REGION.rep.googleapis.com

    Informationen zum Registrieren von Endpunkten finden Sie unter Endpunkte registrieren. Außerdem muss der Agent für diese Endpunkte die Rolle „IAP-Ausgang“ haben. Eine Anleitung finden Sie unter Ausgangsrichtlinie für Agent zu Endpunkt erstellen policy.

  6. Prüfen Sie die Agentkonfiguration.

    Console

    1. Rufen Sie in der Google Cloud Console die Seite Deployments der Agent Platform auf.

      Zu Deployments

    2. Klicken Sie auf den Namen des bereitgestellten Agent.

    3. Klicken Sie auf Dienstkonfiguration. Der Bereich Beobachtbarkeit für den Agent wird geöffnet.

    4. Klicken Sie auf Bereitstellungsdetails. Die Ingress- und Egress-Konfigurationen des Agent Gateway sind im Feld Bereitstellungsspezifikation verfügbar.

    gcloud

    Verwenden Sie die folgende REST API-Anfrage, um zu prüfen, ob der Agent jetzt mit dem Gateway verknüpft ist. Wenn die Ausgabe null ist, konnte die Runtime keine Verbindung zum Gateway herstellen.

    curl -s -X GET \
      -H "Authorization: Bearer $(gcloud auth print-access-token)" \
      "https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID" \
      | jq '.spec.deploymentSpec.agentGatewayConfig'

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die Projekt-ID
    • REGION: die Region, in der der Agent bereitgestellt wird
    • RESOURCE_ID: die Ressourcen-ID des Agent

Benutzerdefinierte Container-Agents (BYOC) für das Agent Gateway konfigurieren

Wenn Sie ausgehenden Traffic für einen Agent, der mit einem benutzerdefinierten Container-Image bereitgestellt wurde (Bring Your Own Container, BYOC), über ein Agent Gateway für „Agent zu beliebigem Ziel (ausgehend)“ leiten möchten, müssen Sie das Root-Zertifikat der Zertifizierungsstelle (CA) des Gateways in den Trust Store des benutzerdefinierten Container-Image einbinden.

Da das Agent Gateway die TLS-Entschlüsselung und -Prüfung für die ausgehende Agentkommunikation durchführt, wird das Zertifikat der Zertifizierungsstelle bei nicht BYOC-Agentbereitstellungen (quellbasiert) automatisch während der Imageerstellung eingefügt. Bei benutzerdefinierten Container-Images müssen Sie das CA-Zertifikat des Gateways explizit abrufen, es in den Trust Store der System-CA in Ihrem Dockerfile installieren und die Umgebungsvariablen für das Zertifikatpaket festlegen, die von Python SDKs, HTTP-Clientbibliotheken und gRPC benötigt werden.

So konfigurieren Sie ein BYOC-Container-Image für den ausgehenden Traffic des Agent Gateway:

  1. Rufen Sie die Root-Zertifikate aus der Agent Gateway-Ressource ab.

    Exportieren Sie die PEM-String des CA-Root-Zertifikats direkt aus dem Feld agentGatewayCard.rootCertificates Ihrer Agent Gateway-Ressource:

    export AGW_CERT=$(gcloud network-services agent-gateways describe AGENT_GATEWAY_NAME \
       --location=REGION \
       --project=PROJECT_ID \
       --format="value[delimiter=\\n](agentGatewayCard.rootCertificates)")

    Alternativ können Sie die REST API verwenden, um die Gateway-Ressource abzurufen:

    curl -s -X GET \
       -H "Authorization: Bearer $(gcloud auth print-access-token)" \
       "https://networkservices.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME" \
       | jq -r '.agentGatewayCard.rootCertificates[]'

    Ersetzen Sie Folgendes:

    • AGENT_GATEWAY_NAME: der Name Ihres Agent Gateway für ausgehenden Traffic
    • REGION: die Region, in der das Gateway bereitgestellt wird
    • PROJECT_ID: die Projekt-ID
  2. Aktualisieren Sie Ihr Dockerfile, um das CA-Zertifikat als vertrauenswürdig einzustufen.

    Fügen Sie das Build-Argument AGENT_GATEWAY_ROOT_CERTIFICATES zu Ihrem Dockerfile hinzu. Die Build-Befehle teilen die Zertifikate in separate Dateien auf, installieren sie mit update-ca-certificates und legen Umgebungsvariablen fest, damit OpenSSL, Python-HTTP-Clientbibliotheken (requests, httpx) und gRPC die benutzerdefinierte Zertifizierungsstelle erkennen:

    # Install root certificates under root user
    USER root
    
    ARG AGENT_GATEWAY_ROOT_CERTIFICATES
    RUN if [ -n "$AGENT_GATEWAY_ROOT_CERTIFICATES" ]; then \
         echo "Installing Agent Gateway root certificates..."; \
         printf "%b" "$AGENT_GATEWAY_ROOT_CERTIFICATES" | awk 'BEGIN {c=0} /BEGIN CERTIFICATE/ {c++} c > 0 { print > "/usr/local/share/ca-certificates/agw-" c ".crt" }'; \
         update-ca-certificates; \
       fi
    
    # Configure SSL/TLS trust paths for Python HTTP libraries, OpenSSL, and gRPC
    ENV GRPC_DEFAULT_SSL_ROOTS_FILE_PATH=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt}
    ENV REQUESTS_CA_BUNDLE=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt}
    ENV SSL_CERT_FILE=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt}
    ENV AGENT_GATEWAY_ROOT_CERT_302034098528=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt}
    
    # Switch back to application execution user
    USER 1000
  3. Erstellen Sie mithilfe von Cloud Build das Container-Image.

    Erstellen Sie eine cloudbuild.yaml-Datei, um den Root-Zertifikatstring mithilfe von Substitutionen an Cloud Build zu übergeben:

    steps:
    - name: 'gcr.io/cloud-builders/docker'
      args:
      - 'build'
      - '--build-arg'
      - 'AGENT_GATEWAY_ROOT_CERTIFICATES=${_AGW_CERT}'
      - '-t'
      - '$_IMAGE_URI'
      - '.'
    
    images:
    - '$_IMAGE_URI'
    

    Senden Sie den Container-Image-Build an Cloud Build:

    export IMAGE_URI="REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME:latest"
    
    gcloud builds submit \
       --project=PROJECT_ID \
       --region=REGION \
       --config=cloudbuild.yaml \
       --substitutions=_IMAGE_URI="$IMAGE_URI",_AGW_CERT="$AGW_CERT" \
       .
    

    Ersetzen Sie REPOSITORY_NAME und IMAGE_NAME durch die Namen Ihres Artifact Registry-Repositorys und -Image.

  4. Stellen Sie Ihren containerisierten Agent bereit.

    Geben Sie die URI des erstellten Container-Image zusammen mit Ihrer Agent Gateway-Konfiguration in Ihrer Bereitstellungsanfrage an (mit agent_gateway_config unter spec.deploymentSpec oder mit SDK-Bereitstellungsaufrufen).

Agent Runtime auf genehmigte Agent Gateways beschränken

Sie können benutzerdefinierte Einschränkungen für Organisationsrichtlinien erstellen, um die Gruppe der infrage kommenden Agent Gateway-Ressourcen zu definieren, die beim Bereitstellen von Agents verwendet werden können.

Benutzerdefinierte Einschränkungen für Organisationsrichtlinien erstellen

In diesem Beispiel werden benutzerdefinierte Einschränkungen erstellt, die nur Traffic zu und von einer vorab genehmigten Liste von Gateways zulassen.

Agent zu beliebigem Ziel

  1. Erstellen Sie eine Datei mit dem Namen constraint-agent-gateway-egress.yaml, um eine benutzerdefinierte Einschränkung für den Modus „Agent zu beliebigem Ziel (ausgehend)“ zu definieren.

    Im folgenden Beispiel gibt das Feld condition an, dass der Vorgang nur zulässig ist, wenn eine Agent Gateway-Ressource angegeben ist (Feld ist vorhanden und nicht leer) und wenn sich das angegebene Gateway in der vorab genehmigten Liste befindet.

    name: organizations/ORGANIZATION_ID/customConstraints/custom.allowlistedEgressAgentGatewaysForAgentEngine
    resource_types:
    - aiplatform.googleapis.com/ReasoningEngine
    condition: >-
    has(resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway) &&
    resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway != '' &&
    (resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway in [
      'projects/AGENT_PROJECT_ID_1/locations/REGION_1/agentGateways/AGENT_GATEWAY_ID_1',
      'projects/AGENT_PROJECT_ID_2/locations/REGION_2/agentGateways/AGENT_GATEWAY_ID_2',
    ])
    method_types:
    - CREATE
    - UPDATE
    action_type: ALLOW
    display_name: Restrict Reasoning Engine Egress to Approved Agent Gateways
    description: Reasoning Engines can only be bound to a pre-approved list of
    Agent Gateway instances. Binding to any other gateway is denied.
    

    Ersetzen Sie Folgendes:

    • ORGANIZATION_ID: Ihre Organisations-ID.
    • AGENT_PROJECT_ID: Ihre Projekt-ID.
    • REGION: die Region, in der das Gateway erstellt wurde.
    • AGENT_GATEWAY_ID: Ihre Gateway-ID.
  2. Wenden Sie die benutzerdefinierte Einschränkung an.

    gcloud org-policies set-custom-constraint EGRESS_CONSTRAINT_PATH
    

    Ersetzen Sie EGRESS_CONSTRAINT_PATH durch den vollständigen Pfad zur benutzerdefinierten Einschränkungsdatei, die Sie im vorherigen Schritt erstellt haben.

  3. Erstellen Sie die Organisationsrichtlinie, um die Einschränkung zu erzwingen. Erstellen Sie eine YAML-Richtliniendatei mit dem Namen policy-agent-gateway-egress.yaml, um die Organisationsrichtlinie zu definieren. In diesem Beispiel wird diese Einschränkung auf Projektebene erzwungen. Sie können diese Einschränkung aber auch auf Organisations- oder Ordnerebene festlegen.

    name: projects/AGENT_PROJECT_ID/policies/custom.allowlistedEgressAgentGatewaysForAgentEngine
    spec:
      rules:
      - enforce: true
    

    Ersetzen Sie AGENT_PROJECT_ID durch Ihre Projekt-ID.

  4. Erzwingen Sie die Organisationsrichtlinie.

    gcloud org-policies set-policy EGRESS_POLICY_PATH
    

    Ersetzen Sie EGRESS_POLICY_PATH durch den vollständigen Pfad zur YAML-Datei der Organisationsrichtlinie, die Sie im vorherigen Schritt erstellt haben. Es kann bis zu 15 Minuten dauern, bis die Richtlinie wirksam wird.

Client zu Agent

  1. Erstellen Sie eine Datei mit dem Namen constraint-agent-gateway-ingress.yaml, um eine benutzerdefinierte Einschränkung für den Modus „Client zu Agent (eingehend)“ zu definieren.

    Im folgenden Beispiel gibt das Feld condition an, dass der Vorgang nur zulässig ist, wenn eine Agent Gateway-Ressource angegeben ist (Feld ist vorhanden und nicht leer) und wenn sich das angegebene Gateway in der vorab genehmigten Liste befindet.

    name: organizations/ORGANIZATION_ID/customConstraints/custom.allowlistedIngressAgentGatewaysForAgentEngine
    resource_types:
    - aiplatform.googleapis.com/ReasoningEngine
    condition: >-
    has(resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway) &&
    resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway != '' &&
    (resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway in [
      'projects/AGENT_PROJECT_ID_1/locations/REGION_1/agentGateways/AGENT_GATEWAY_ID_1',
      'projects/AGENT_PROJECT_ID_2/locations/REGION_2/agentGateways/AGENT_GATEWAY_ID_2',
    ])
    method_types:
    - CREATE
    - UPDATE
    action_type: ALLOW
    display_name: Restrict Reasoning Engine Ingress to Approved Agent Gateways
    description: Reasoning Engines can only be bound to a pre-approved list of
    Agent Gateway instances. Binding to any other gateway is denied.
    

    Ersetzen Sie Folgendes:

    • ORGANIZATION_ID: Ihre Organisations-ID.
    • AGENT_PROJECT_ID: Ihre Projekt-ID.
    • REGION: die Region, in der das Gateway erstellt wurde.
    • AGENT_GATEWAY_ID: Ihre Gateway-ID.
  2. Wenden Sie die benutzerdefinierte Einschränkung an.

    gcloud org-policies set-custom-constraint INGRESS_CONSTRAINT_PATH
    

    Ersetzen Sie INGRESS_CONSTRAINT_PATH durch den vollständigen Pfad zur benutzerdefinierten Einschränkungsdatei, die Sie im vorherigen Schritt erstellt haben.

  3. Erstellen Sie die Organisationsrichtlinie, um die Einschränkung zu erzwingen. Erstellen Sie eine YAML-Richtliniendatei mit dem Namen policy-agent-gateway-ingress.yaml, um die Organisationsrichtlinie zu definieren. In diesem Beispiel wird diese Einschränkung auf Projektebene erzwungen. Sie können diese Einschränkung aber auch auf Organisations- oder Ordnerebene festlegen.

    name: projects/AGENT_PROJECT_ID/policies/custom.allowlistedIngressAgentGatewaysForAgentEngine
    spec:
      rules:
      - enforce: true
    

    Ersetzen Sie AGENT_PROJECT_ID durch Ihre Projekt-ID.

  4. Erzwingen Sie die Organisationsrichtlinie.

    gcloud org-policies set-policy INGRESS_POLICY_PATH
    

    Ersetzen Sie INGRESS_POLICY_PATH durch den vollständigen Pfad zur YAML-Datei der Organisationsrichtlinie , die Sie im vorherigen Schritt erstellt haben. Es kann bis zu 15 Minuten dauern, bis die Richtlinie wirksam wird.

Weitere Informationen zur Verwendung benutzerdefinierter Einschränkungen für Organisationsrichtlinien finden Sie unter Benutzerdefinierte Einschränkungen erstellen.

Nächste Schritte

Codelab

Informationen zum Verwalten agentischer Arbeitslasten mit dem Agent Gateway auf der Gemini Enterprise Agent Platform.

Anleitung

Informationen zum Delegieren der Autorisierung für das Agent Gateway an IAP, Model Armor oder Ihren eigenen benutzerdefinierten Autorisierungsdienst.

Anleitung

Informationen zum Überwachen des Agent Gateway.

Fehlerbehebung

Informationen zur Fehlerbehebung bei der Konnektivität des Agent Gateway.