Autorisierung mit Service Extensions delegieren

Auf dieser Seite erfahren Sie, wie Sie die Autorisierung für Agent Gateway mithilfe von Diensterweiterungen an Identity-Aware Proxy, Model Armor und andere benutzerdefinierte Autorisierungs-Engines delegieren.

Mit Autorisierungsrichtlinien können Sie zentralisierte Zugriffssteuerungs- und Governance-Richtlinien für Traffic erzwingen, der über den vom Agent Gateway veröffentlichten Endpunkt geleitet wird. Mit diesen Richtlinien können Sie Traffic verwalten, indem Sie den Zugriff basierend auf mTLS-Identitäten, Anfrage- und Antwortattributen steuern und sogar an die verwendeten protokollspezifischen Attribute anpassen (z. B. MCP-Server).

Autorisierungsrichtlinien verwenden Richtlinienprofile, um den Typ der auszuführenden Autorisierung zu bestimmen. Sie können eine anfragebasierte Autorisierungsrichtlinie (REQUEST_AUTHZ) verwenden, die auf Informationen in HTTP-Anfrageheadern basiert, um Traffic zuzulassen oder abzulehnen. Alternativ können Sie eine inhaltsbasierte Autorisierungsrichtlinie (CONTENT_AUTHZ) verwenden, wenn Sie die Nutzlasten Ihrer Anwendung genauer prüfen müssen, um Traffic zuzulassen oder abzulehnen.

Weitere Informationen zu Autorisierungsrichtlinien, Richtlinienprofilen und ihren Anwendungsfällen, siehe Übersicht über Autorisierungsrichtlinien.

Autorisierungserweiterungen

Manchmal können komplexe Autorisierungsentscheidungen nicht einfach mit einer Autorisierungsrichtlinie ausgedrückt werden. Mit Agent Gateway können Sie Autorisierungsrichtlinien mit Autorisierungs erweiterungen konfigurieren, um Autorisierungsentscheidungen an benutzerdefinierte Autorisierungs-Engines zu delegieren.

Mit einer Autorisierungserweiterung können Sie Anfragen abfangen und auswerten, die über eine Agent Gateway-Bereitstellung geleitet werden. Dabei wird ein gRPC-Aufruf in Echtzeit an einen externen Dienst gesendet, den Sie verwalten, damit Sie Traffic prüfen, ändern oder sogar blockieren können, bevor er an sein Ziel weitergeleitet wird.

Die Erweiterung prüft die Daten anhand der konfigurierten Autorisierungs richtlinie. Sie können Autorisierungserweiterungen entweder separat für anfragebasierte und inhaltsbasierte Autorisierungsrichtlinien konfigurieren oder beide für umfassende Sicherheit verwenden.

Hinweis

Bevor Sie beginnen, müssen die folgenden Voraussetzungen erfüllt sein:

  • Das Agent Gateway ist bereitgestellt. Weitere Informationen finden Sie unter Agent Gateway konfigurieren.

  • Sie benötigen die IAM-Berechtigung agentGateway.use für die bereitgestellte Agent Gateway-Ressource, um Autorisierungsrichtlinien an das Gateway anhängen zu können.

Autorisierungsrichtlinien mit Erweiterungen konfigurieren

In diesem Abschnitt erfahren Sie, wie Sie Autorisierungsrichtlinien konfigurieren, die Autorisierungs- und Inhaltsicherheitsentscheidungen an Identity-Aware Proxy, Model Armor und andere benutzerdefinierte Dienste delegieren.

Autorisierung an IAP delegieren

Sie können eine Erweiterung für die Anforderungsautorisierung konfigurieren, um Zugriffsentscheidungen für Autorisierungsrichtlinien an IAP zu delegieren.

Im folgenden Beispiel wird gezeigt, wie Sie eine Autorisierungserweiterung mit einer Autorisierungsrichtlinie für eine Agent Gateway-Instanz konfigurieren.

Console

So aktivieren Sie IAP für Agent Gateway über die Google Cloud Console:

  1. Erstellen Sie die erforderlichen IAM-Ausgangsrichtlinien für Ihre Agenten und Tools. Weitere Informationen finden Sie unter IAM-Agent-Richtlinien erstellen.
  2. Unter Agent Gateway im Modus „Agent-to-Anywhere“ (Ausgang) konfigurieren erfahren Sie, wie Sie IAP beim Erstellen des Agent Gateway aktivieren (mit dem Parameter Zugriffsautorisierung).

    Für IAP müssen Ihre Agenten in der Agent Registry-Ressource registriert sein, die an das Gateway gebunden ist.

gcloud

  1. Konfigurieren Sie die Autorisierungserweiterung so, dass sie auf IAP verweist.

    1. Definieren Sie die Erweiterung in einer YAML-Datei. Verwenden Sie die angegebenen Beispielwerte.

      cat >iap-request-authz-extension.yaml <<EOF
      name: my-iap-request-authz-ext
      service: iap.googleapis.com
      failOpen: true
      EOF
      

      Wenn Sie die Erweiterung im reinen Auditmodus bereitstellen möchten, um die Autorisierungsrichtlinie zu testen, ohne sie zu erzwingen, können Sie das Feld DRY_RUN angeben. So können Sie Ihre Richtlinie prüfen und das Risiko von Traffic-Unterbrechungen aufgrund von Konfigurationsfehlern minimieren:

      cat >iap-request-authz-extension.yaml <<EOF
      name: my-iap-request-authz-ext
      service: iap.googleapis.com
      failOpen: true
      metadata: '
        iamEnforcementMode: DRY_RUN
      '
      EOF
      
    2. Importieren Sie die Autorisierungserweiterung. Verwenden Sie den gcloud beta service-extensions authz-extensions import Befehl mit den folgenden Beispielwerten.

      gcloud beta service-extensions authz-extensions import my-iap-request-authz-ext \
         --source=iap-request-authz-extension.yaml \
         --location=LOCATION
      
  2. Konfigurieren Sie im selben Projekt eine Autorisierungsrichtlinie, die die Entscheidung an die Erweiterung delegiert.

    1. Definieren Sie eine Autorisierungsrichtlinie, die die Erweiterung my-iap-authz-request-ext mit Ihrem Gateway verknüpft. Verwenden Sie die angegebenen Beispielwerte.

      cat >iap-request-authz-policy.yaml <<EOF
      name: my-iap-request-authz-policy
      target:
        resources:
          - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
      policyProfile: REQUEST_AUTHZ
      action: CUSTOM
      customProvider:
        authzExtension:
          resources:
            - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-iap-request-authz-ext"
      EOF
      

      Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

    2. Importieren Sie die Autorisierungsrichtlinie in das Projekt. Verwenden Sie den gcloud beta network-security authz-policies import Befehl mit den folgenden Beispielwerten.

      gcloud beta network-security authz-policies import my-iap-request-authz-policy \
         --source=iap-request-authz-policy.yaml \
         --location=LOCATION
      

Autorisierung an Model Armor delegieren

Sie können eine Autorisierungserweiterung konfigurieren, um Entscheidungen zur Inhaltsicherheit für Autorisierungsrichtlinien an Model Armor zu delegieren.

Im folgenden Beispiel wird gezeigt, wie Sie eine solche Autorisierungserweiterung mit einer Autorisierungsrichtlinie für Agent Gateway konfigurieren.

Console

So aktivieren Sie Model Armor für Agent Gateway über die Google Cloud Console:

  1. Erstellen Sie die erforderlichen Model Armor-Vorlagen.

  2. Unter Agent Gateway konfigurieren erfahren Sie, wie Sie Model Armor beim Erstellen des Agent Gateway aktivieren (mit dem Kästchen Model Armor aktivieren). Model Armor-Vorlagen werden sowohl im Modus „Client-to-Agent“ als auch im Modus „Agent-to-Anywhere“ unterstützt.

  3. Wenn sich Ihre Model Armor-Vorlagen in einem anderen Projekt als das Gateway befinden, müssen Sie dem Agent Gateway-Dienstkonto manuell die erforderlichen Rollen zuweisen. Das Dienstkonto hat das Format: service-PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com, wobei PROJECT_NUMBER die Projektnummer des Projekts ist, in dem Sie das Gateway erstellt haben.

    Weisen Sie die folgenden Rollen zu:

    • Die Rollen roles/modelarmor.calloutUser und roles/serviceusage.serviceUsageConsumer im Projekt, das das Gateway enthält.
    • Die Rolle roles/modelarmor.user im Projekt, das die Model Armor-Vorlagen enthält.

    Sie müssen die gcloud CLI verwenden, um diesen Schritt auszuführen.

    gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
     --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
     --role=roles/modelarmor.calloutUser
    gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
     --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
     --role=roles/serviceusage.serviceUsageConsumer
    gcloud projects add-iam-policy-binding MODEL_ARMOR_PROJECT_ID \
     --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
     --role=roles/modelarmor.user
    

    Ersetzen Sie Folgendes:

    • GATEWAY_PROJECT_ID: Die Projekt-ID des Projekts, in dem Sie das Gateway erstellt haben.
    • GATEWAY_PROJECT_NUMBER: Die Projektnummer des Projekts, in dem Sie das Gateway erstellt haben.
    • MODEL_ARMOR_PROJECT_ID: Die Projekt-ID des Projekts, das die Model Armor-Vorlage enthält.

    Wenn Sie das Gateway für Agent Runtime verwenden, benötigt das Reasoning Engine-Dienstkonto auch diese Berechtigungen, wie unter Agent Runtime-Traffic über Agent Gateway weiterleiten beschrieben.

gcloud

  1. Erstellen Sie die erforderlichen Model Armor-Vorlagen.

  2. Wenn sich Ihre Model Armor-Vorlagen in einem anderen Projekt als das Gateway befinden, müssen Sie dem Agent Gateway-Dienstkonto manuell die erforderlichen Rollen zuweisen. Das Dienstkonto hat das Format: service-PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com, wobei PROJECT_NUMBER die Projektnummer des Projekts ist, in dem Sie das Gateway erstellt haben.

    Weisen Sie die folgenden Rollen zu:

    • Die Rollen roles/modelarmor.calloutUser und roles/serviceusage.serviceUsageConsumer im Projekt, das das Gateway enthält.
    • Die Rolle roles/modelarmor.user im Projekt, das die Model Armor-Vorlage enthält.
    gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
     --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
     --role=roles/modelarmor.calloutUser
    gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
     --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
     --role=roles/serviceusage.serviceUsageConsumer
    gcloud projects add-iam-policy-binding MODEL_ARMOR_PROJECT_ID \
     --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
     --role=roles/modelarmor.user
    

    Ersetzen Sie Folgendes:

    • GATEWAY_PROJECT_ID: Die Projekt-ID des Projekts, in dem Sie das Gateway erstellt haben.
    • GATEWAY_PROJECT_NUMBER: Die Projektnummer des Projekts, in dem Sie das Gateway erstellt haben.
    • MODEL_ARMOR_PROJECT_ID: Die Projekt-ID des Projekts, das die Model Armor-Vorlage enthält.
  3. Konfigurieren Sie die Autorisierungserweiterung so, dass sie auf Model Armor verweist.

    1. Definieren Sie die Erweiterung in einer YAML-Datei. Verwenden Sie die angegebenen Beispielwerte.

      cat >ma-content-authz-extension.yaml <<EOF
      name: my-ma-content-authz-ext
      service: modelarmor.LOCATION.rep.googleapis.com
      metadata:
        model_armor_settings: '[
          {
          "response_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/TEMPLATE_ID",
          "request_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/TEMPLATE_ID"
          }
        ]'
      failOpen: true
      timeout: 1s
      EOF
      
    2. Importieren Sie die Autorisierungserweiterung. Verwenden Sie den gcloud beta service-extensions authz-extensions import Befehl mit den folgenden Beispiel werten.

      gcloud beta service-extensions authz-extensions import my-ma-content-authz-ext \
         --source=ma-content-authz-extension.yaml \
         --location=LOCATION
      
  4. Konfigurieren Sie eine Autorisierungsrichtlinie mit der Erweiterung.

    1. Definieren Sie eine Autorisierungsrichtlinie, die die Erweiterung my-ma-content-authz-ext mit einem Agent Gateway verknüpft.

      cat >ma-content-authz-policy.yaml <<EOF
      name: my-ma-content-authz-policy
      target:
        resources:
          - "projects/PROJECT_ID/locations/LOCATION/gateways/AGENT_GATEWAY_NAME"
      policyProfile: CONTENT_AUTHZ
      action: CUSTOM
      customProvider:
        authzExtension:
          resources:
            - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-ma-content-authz-ext"
      EOF
      

      Für Richtlinien zur Inhaltsautorisierung ist der Wert von policyProfile auf CONTENT_AUTHZ festgelegt. Dieser Wert gibt an, dass der benutzerdefinierte Richtlinienanbieter den Anfrage- und Antworttraffic einschließlich der Textverarbeitung verarbeitet.

    2. Importieren Sie die Autorisierungsrichtlinie in das Projekt. Verwenden Sie den gcloud beta network-security authz-policies import Befehl mit den folgenden Beispielwerten.

      gcloud beta network-security authz-policies import my-ma-content-authz-policy \
        --source=ma-content-authz-policy.yaml \
        --location=LOCATION
      

Autorisierung an benutzerdefinierte Autorisierungserweiterungen delegieren

Sie können benutzerdefinierte Autorisierungserweiterungen konfigurieren, um Entscheidungen an benutzerdefinierte Dienste zu delegieren. Diese benutzerdefinierten Erweiterungen können nur auf voll qualifizierte Domainnamen (FQDNs) ausgerichtet sein.

Wenn Sie FQDN-Ziele verwenden, verwendet die Erweiterung das HTTP2-Protokoll mit TLS-Verschlüsselung, um mit Endpunkten auf Port 443 zu kommunizieren. Das Serverzertifikat wird jedoch nicht von der Erweiterung validiert. Aus Sicherheitsgründen müssen Sie daher dafür sorgen, dass sich die aufgelösten Endpunkte im VPC-Netzwerk befinden. Achten Sie außerdem darauf, dass DNS-Peering zwischen dem Agent Gateway-Projekt und Ihrem VPC-Netzwerk eingerichtet ist.

  1. Wenn Sie eine Autorisierungserweiterung mit einer Autorisierungsrichtlinie für einen bestimmten FQDN wie mycustomauthz.internal.net konfigurieren möchten, geben Sie ihn als Wert für service in der YAML-Datei der Erweiterung an, wie im folgenden Beispiel gezeigt. In diesem Beispiel wird davon ausgegangen, dass Sie einen Server in Ihrem VPC-Netzwerk bereitgestellt haben, der das ext_authz-Protokoll implementiert.

    cat >custom-authz-extension.yaml <<EOF
    name: my-custom-authz-ext
    service: mycustomauthz.internal.net
    failOpen: true
    wireFormat: EXT_AUTHZ_GRPC
    EOF
    
  2. Erstellen Sie die Autorisierungserweiterung, die auf den benutzerdefinierten Dienst verweist.

      gcloud beta service-extensions authz-extensions import custom-authz-extension 
    --source=custom-authz-extension.yaml
    --location=LOCATION

  3. Nachdem Sie die Erweiterung erstellt haben, konfigurieren Sie eine CUSTOM-Autorisierungsrichtlinie, die Entscheidungen an die Autorisierungserweiterung delegiert.

      $ cat >authz-policy.yaml <<EOF
      name: authz-with-extension
      target:
        resources:
        - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
      policyProfile: REQUEST_AUTHZ
      action: CUSTOM
      customProvider:
      authzExtension:
        resources:
        - projects/PROJECT_ID/locations/LOCATION/authzExtensions/custom-authz-extension
      EOF
    
  4. Erstellen Sie die Autorisierungsrichtlinie.

    gcloud beta network-security authz-policies import authz-policy-with-extension \
    --source=authz-policy.yaml \
    --location=LOCATION
    

Wenn eine Autorisierungserweiterung mit einer Autorisierungsrichtlinie verknüpft ist, die das Profil REQUEST_AUTHZ verwendet, wie in diesem Beispiel gezeigt, ruft das Gateway die Erweiterung nur auf, wenn Anfrageheader eingehen. Der Anfragetext, die Antwortheader und der Antworttext sind für die Autorisierungserweiterung nicht sichtbar.

IAP-Autorisierung mit Model Armor-Leitplanken kombinieren

Für umfassende Sicherheit empfehlen wir, eine CUSTOM-Autorisierungsrichtlinie mit einem REQUEST_AUTHZ-Richtlinienprofil und eine weitere CUSTOM-Autorisierungsrichtlinie mit einem CONTENT_AUTHZ-Richtlinienprofil einzurichten.

Im folgenden Beispiel wird IAP als zentralisiertes System für die Anforderungsautorisierung und Model Armor für KI-Leitplanken verwendet. Wie in den vorherigen Beispielen gezeigt, können Sie diese jeweils durch Diensterweiterungen ersetzen, um Ihre eigenen benutzerdefinierten Lösungen zu verwenden.

  1. Konfigurieren Sie eine REQUEST_AUTHZ-Autorisierungserweiterung, die an IAP delegiert, und eine Autorisierungsrichtlinie, die auf die Erweiterung verweist.

    1. Definieren Sie die Autorisierungserweiterung.

      $ cat >iap-extension.yaml <<EOF
      name: iap-extension
      service: iap.googleapis.com
      failOpen: true
      EOF
      
    2. Erstellen Sie die Autorisierungserweiterung.

      gcloud beta service-extensions authz-extensions import iap-extension \
      --source=iap-extension.yaml \
      --location=LOCATION
      

      Ersetzen Sie LOCATION durch die Region der Erweiterung.

    3. Konfigurieren Sie die REQUEST_AUTHZ-Autorisierungsrichtlinie, die an die Erweiterung delegiert.

      $ cat >authz-policy-request-authz.yaml <<EOF
      name: authz-iap
      target:
        resources:
        - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
      policyProfile: REQUEST_AUTHZ
      action: CUSTOM
      customProvider:
        authzExtension:
          resources:
          - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/iap-extension"
      EOF
      

      Ersetzen Sie Folgendes:

      • PROJECT_ID: Ihre Projekt-ID.
      • LOCATION: Der Standort der Ressourcen.
      • AGENT_GATEWAY_NAME: Der Name des Agent Gateway.
    4. Erstellen Sie die Autorisierungsrichtlinie.

      gcloud beta network-security authz-policies import authz-iap \
      --source=authz-policy-request-authz.yaml \
      --location=LOCATION
      
  2. Konfigurieren Sie eine CONTENT_AUTHZ-Autorisierungserweiterung, die an Model Armor delegiert, und eine Autorisierungsrichtlinie, die auf die Erweiterung verweist.

    1. Definieren Sie die Erweiterung.

      $ cat >ma-extension-file.yaml <<EOF
      name: ma-extension
      service: modelarmor.LOCATION.rep.googleapis.com
      metadata:
        model_armor_settings: '[
          {
          "response_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID",
          "request_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID"
          }
        ]'
      failOpen: true
      timeout: 1s
      EOF
      

      Ersetzen Sie Folgendes:

      • LOCATION: Die Region, in der sich Ihre Model Armor-Vorlagen befinden.
      • MODEL_ARMOR_PROJECT_ID: Die Projekt-ID des Projekts, das die Model Armor-Vorlagen enthält.
      • RESPONSE_TEMPLATE_ID: Die ID der Antwortvorlage.
      • REQUEST_TEMPLATE_ID: Die ID der Anfragevorlage.
    2. Erstellen Sie die Autorisierungserweiterung.

      gcloud beta service-extensions authz-extensions import ma-extension \
      --source=ma-extension-file.yaml \
      --location=LOCATION
      
    3. Konfigurieren Sie die CONTENT_AUTHZ-Autorisierungsrichtlinie, die an die Erweiterung delegiert.

      $ cat >authz-policy-content-authz.yaml <<EOF
      name: authz-ma
      target:
        resources:
        - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
      policyProfile: CONTENT_AUTHZ
      action: CUSTOM
      customProvider:
        authzExtension:
          resources:
          - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/ma-extension"
      EOF
      
    4. Erstellen Sie die Autorisierungsrichtlinie.

      gcloud beta network-security authz-policies import ma-authz-policy \
      --source=authz-policy-content-authz.yaml \
      --location=LOCATION
      

Wenn eine Autorisierungserweiterung mit einem CONTENT_AUTHZ-Profil verknüpft ist, empfängt sie alle ext_proc-Ereignisse, einschließlich Anfrage- und Antwortheader, Text und Trailer. Wenn Ihre ext_proc-basierte Autorisierungserweiterung sowohl die Autorisierung zur Anfragezeit als auch die inhaltsbasierte Autorisierung verarbeiten kann, empfehlen wir, eine einzelne CUSTOM-Autorisierungsrichtlinie mit dem CONTENT_AUTHZ-Richtlinienprofil zu konfigurieren. Diese Richtlinie sollte auf Ihre vielseitige Autorisierungserweiterung verweisen. Dieser Ansatz ermöglicht beide Arten der Autorisierung über eine einzige Erweiterung und ext_proc-Verbindung, was die Latenz im Vergleich zur Verwendung separater Erweiterungen für REQUEST_AUTHZ- und CONTENT_AUTHZ-Profile verbessern kann.

Autorisierung basierend auf MCP-Protokollattributen

Agent Gateway parst die MCP-Protokollnutzlast in einer Anfrage und stellt die extrahierten Attribute für Autorisierungsrichtlinien zur Verfügung.

Sie können den Zugriff basierend auf MCP-Methodenparametern wie den Namen bestimmter Tools einschränken. In diesem Abschnitt finden Sie zwei Beispiele, eines für eine ALLOW-Richtlinie und eines für DENY.

  1. Konfigurieren Sie die Autorisierungsrichtlinie.

    Beispiel für eine ALLOW-Richtlinie

    In diesem Beispiel wird der Zugriff auf eine bestimmte Gruppe von Tools auf dem MCP-Server und die Basisprotokollfunktionen zugelassen, der Zugriff auf Prompts und Ressourcen jedoch nicht.

    Wenn Sie eine ALLOW-Richtlinie schreiben, geben Sie baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS an, damit nicht zugriffsspezifische MCP-RPCs wie „initialize“, „logging“, „completion“, „notifications“ und „ping“ weiterhin funktionieren. Andernfalls kann keine MCP-Sitzung eingerichtet werden.

    $ cat >authz-policy-restrict-tools.yaml <<EOF
    name: my-authz-policy-restrict-tools
    target:
      resources:
      - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
    policyProfile: REQUEST_AUTHZ
    httpRules:
    - to:
        operations:
        - mcp:
            baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS
            methods:
            - name: "tools/list"
            - name: "tools/call"
              params:
              - exact: "get_weather"
              - exact: "get_location"
    action: ALLOW
    EOF
    

    Beispiel für eine DENY-Richtlinie

    In diesem Beispiel wird der Zugriff auf alle Prompts/ Methoden für einen MCP-Server hinter einem Agent Gateway verweigert.

    $ cat >authz-policy-disallow-prompts.yaml <<EOF
    name: my-authz-policy-disallow-prompts
    target:
      resources:
      - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
    policyProfile: REQUEST_AUTHZ
    httpRules:
    - to:
        operations:
        - mcp:
            methods:
            - name: "prompts"
    action: DENY
    EOF
    
  2. Erstellen Sie die Autorisierungsrichtlinie.

    gcloud beta network-security authz-policies import AUTHZ_POLICY_NAME \
    --source=AUTH_POLICY_YAML_FILE_PATH \
    --location=LOCATION
    

    Ersetzen Sie Folgendes:

    • AUTHZ_POLICY_NAME: Der Name der Autorisierungsrichtlinie.
    • AUTH_POLICY_YAML_FILE_PATH: Der Pfad zur YAML-Datei der Autorisierungsrichtlinie.
    • LOCATION: Der Standort der Ressourcen.

Beschränkungen

Bei der Verwendung von Autorisierungsrichtlinien gelten die folgenden Beschränkungen:

  • Sie können maximal vier benutzerdefinierte Autorisierungsrichtlinien pro Agent Gateway konfigurieren, unabhängig vom Richtlinienprofil.
  • Wenn Sie benutzerdefinierte Autorisierungserweiterungen mit dem Profil CONTENT_AUTHZ verwenden, müssen diese das ext_proc-Protokoll und den Modus FULL_DUPLEX_STREAMED für Text-Ereignisse unterstützen.
  • Wenn Sie mehrere benutzerdefinierte Autorisierungsrichtlinien konfigurieren, die dasselbe Profil verwenden, ist die Ausführungsreihenfolge nicht garantiert.

Weitere Informationen zu den Beschränkungen von Autorisierungserweiterungen finden Sie in den folgenden Abschnitten:

Nächste Schritte

Leitfaden

Informationen zum Überwachen von Agent Gateway.