Autorisierung mit Service Extensions delegieren

Auf dieser Seite erfahren Sie, wie Sie die Autorisierung für das Agenten-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 Agenten-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 dem Agenten-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 Agenten-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 Agenten-Gateway ist bereitgestellt. Weitere Informationen finden Sie unter Konfigurieren Agenten-Gateway.

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

Autorisierungsrichtlinien mit Erweiterungen konfigurieren

In diesem Abschnitt wird beschrieben, 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.

In den folgenden Schritten wird beschrieben, wie Sie eine Autorisierungserweiterung mit einer Autorisierungsrichtlinie für eine Agenten-Gateway-Instanz konfigurieren.

  1. Erstellen Sie die erforderlichen IAM-Richtlinien für ausgehenden Traffic für Ihre Agenten und Tools. Weitere Informationen finden Sie unter IAM-Agenten richtlinien erstellen.

  2. Unter Agenten-Gateway im Modus „Agent zu beliebigem Ziel (ausgehend)“ konfigurieren erfahren Sie, wie Sie IAP aktivieren, während Sie das Agenten-Gateway erstellen (mit dem Parameter Zugriffsautorisierung).

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

  3. Konfigurieren Sie eine Autorisierungserweiterung, die 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
timeout: 1s
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 überprü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
timeout: 1s
metadata:
  iamEnforcementMode: "DRY_RUN"
EOF

      Entfernen Sie das Metadatenfeld DRY_RUN, wenn Sie Richtlinien erzwingen möchten.

    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

  4. Konfigurieren Sie im selben Projekt eine Autorisierungsrichtlinie, die die Entscheidung an die Erweiterung delegiert.

    1. Definieren Sie eine Autorisierungsrichtlinie, die die Erweiterung my-iap-request-authz-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 das Agenten-Gateway konfigurieren.

Console

So aktivieren Sie Model Armor für das Agenten-Gateway über die Google Cloud Console:

  1. Erstellen Sie die erforderlichen Model Armor-Vorlagen.

  2. Unter Agenten-Gateway konfigurieren erfahren Sie, wie Sie Model Armor aktivieren, während Sie das Agenten-Gateway erstellen (mit dem Kästchen Model Armor aktivieren). Model Armor-Vorlagen werden sowohl im Modus „Client zu Agent“ als auch im Modus „Agent zu beliebigem Ziel“ unterstützt.

  3. Wenn sich Ihre Model Armor-Vorlagen in einem anderen Projekt als das Gateway befinden, müssen Sie dem Dienstkonto des Agenten-Gateways die erforderlichen Rollen manuell 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 die Agenten-Laufzeitumgebung verwenden, benötigt der Reasoning Engine-Dienst-Agent auch diese Berechtigungen, wie unter Agenten-Laufzeitumgebung-Traffic über das Agenten-Gateway leiten 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 Dienstkonto des Agenten-Gateways die erforderlichen Rollen manuell 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, die 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 Agenten-Gateway verknüpft.

      Agent zu beliebigem Ziel 

      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"
httpRules:
  - to:
      operations: [ { "paths": [ { "prefix": "/" } ] } ]
    when: >
      request.headers['content-type'] == 'application/json' ||
      request.headers['content-type'].startsWith('text/')
EOF

      Wichtige Hinweise:

      • Der Wert von policyProfile ist auf CONTENT_AUTHZ festgelegt. Das bedeutet, dass der benutzerdefinierte Richtlinienanbieter Anfragen- und Antworttraffic einschließlich des Anfragetexts verarbeitet.

      • Der httpRules Parameter zeigt, wie Sie mit CEL Attributen Bedingungen erstellen, die mit dem spezifischen Traffic übereinstimmen, den Sie zur Auswertung an Model Armor weiterleiten möchten. In diesem Beispiel stimmen die Regeln mit dem gesamten Traffic mit den Inhaltstypen application/json oder text/ überein. Wir empfehlen, solche Regeln zu verwenden, um die Model Armor-Auswertung auf relevanten Traffic zu beschränken. So können Sie unterstützten LLM API-, MCP- und A2A-Traffic an Model Armor weiterleiten und gleichzeitig internen Traffic wie gRPC-Aufrufe von Agenten ausschließen.

      Client zu Agent 

      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

      Der Wert von policyProfile ist auf CONTENT_AUTHZ festgelegt. Das bedeutet, dass der benutzerdefinierte Richtlinienanbieter Anfragen- und Antworttraffic einschließlich des Anfragetexts 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 vollqualifizierte 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 Agenten-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
timeout: 1s
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

Beachten Sie, dass, wenn eine Autorisierungserweiterung mit einer Autorisierungsrichtlinie verknüpft ist, die das Profil REQUEST_AUTHZ verwendet, wie in diesem Beispiel gezeigt, das Gateway die Erweiterung nur aufruft, 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 benutzerdefinierte Autorisierungsrichtlinie mit einem REQUEST_AUTHZ-Richtlinienprofil und eine weitere benutzerdefinierte 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
timeout: 1s
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 Agenten-Gateways.

    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

Das Agenten-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 Agenten-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 Einschränkungen:

  • Sie können maximal vier benutzerdefinierte Autorisierungsrichtlinien pro Agenten-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

Anleitung

Informationen zum Überwachen des Agenten-Gateways.