Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Autorisierung mit Service Extensions delegieren

Auf dieser Seite erfahren Sie, wie Sie die Autorisierung für Agent Gateway mithilfe von Service Extensions 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 den vom Agent Gateway veröffentlichten Endpunkt durchläuft. Mit diesen Richtlinien können Sie den Traffic verwalten, indem Sie den Zugriff auf Grundlage von mTLS-Identitäten, Anfrage- und Antwortattributen steuern. Sie können die Richtlinien sogar anhand der verwendeten protokollspezifischen Attribute anpassen (z. B. MCP-Server).

In Autorisierungsrichtlinien wird anhand von Richtlinienprofilen festgelegt, welche Art von Autorisierung durchgeführt werden soll. 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 finden Sie unter Autorisierungsrichtlinien – Übersicht.

Autorisierungserweiterungen

Manchmal lassen sich komplexe Autorisierungsentscheidungen nicht ohne Weiteres mit einer Autorisierungsrichtlinie ausdrücken. Mit Agent Gateway können Sie Autorisierungsrichtlinien mit Autorisierungserweiterungen konfigurieren, um Autorisierungsentscheidungen an benutzerdefinierte Autorisierungs-Engines zu delegieren.

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

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

Hinweis

Bevor Sie beginnen, sollten Sie prüfen, ob die folgenden Anforderungen erfüllt sind:

Das KI-Agenten-Gateway wird 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 anzuhängen.

Autorisierungsrichtlinien mit Erweiterungen konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie Autorisierungsrichtlinien konfigurieren, mit denen Autorisierungs- und Content-Safety-Entscheidungen an Identity-Aware Proxy, Model Armor und andere benutzerdefinierte Dienste delegiert werden.

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 Agent Gateway-Instanz konfigurieren.

Erstellen Sie die erforderlichen IAM-Richtlinien für ausgehenden Traffic für Ihre Agents und Tools. Weitere Informationen finden Sie unter IAM-Agent-Richtlinien erstellen.
Unter Agenten-Gateway im Modus „Agent-to-Anywhere“ (Ausgang) konfigurieren finden Sie Informationen zum Aktivieren von IAP beim Erstellen des Agenten-Gateways (mit dem Parameter Zugriffsberechtigung).

Für IAP müssen Ihre Agents in der Agent Registry-Ressource registriert sein, die an das Gateway gebunden ist.
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 Prüfmodus 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 minimieren, dass der Traffic aufgrund von Konfigurationsfehlern unterbrochen wird:
```
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 bereit sind, Richtlinien durchzusetzen.
2. Importieren Sie die Autorisierungserweiterung. Verwenden Sie den Befehl gcloud beta service-extensions authz-extensions import mit den folgenden Beispielwerten.
```
gcloud beta service-extensions authz-extensions import my-iap-request-authz-ext \
    --source=iap-request-authz-extension.yaml \
    --location=LOCATION
```

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

Definieren Sie eine Autorisierungsrichtlinie, die die Erweiterung my-iap-request-authz-ext mit Ihrem Gateway verknüpft. Verwenden Sie die bereitgestellten 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 dabei PROJECT_ID durch Ihre Projekt-ID.

Importieren Sie die Autorisierungsrichtlinie in das Projekt. Verwenden Sie den Befehl gcloud beta network-security authz-policies import 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.

Das folgende Beispiel zeigt, 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:

Erstellen Sie die erforderlichen Model Armor-Vorlagen.
Unter Agenten-Gateway konfigurieren finden Sie Informationen zum Aktivieren von Model Armor beim Erstellen des Agenten-Gateways (mithilfe des Kästchens Model Armor aktivieren). Model Armor-Vorlagen werden sowohl im Client-to-Agent- als auch im Agent-to-Anywhere-Modus unterstützt.
Wenn sich Ihre Model Armor-Vorlagen in einem anderen Projekt als dem Gateway befinden, müssen Sie dem Agent Gateway-Dienstkonto 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.
Für diesen Schritt müssen Sie die gcloud CLI verwenden.
```
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 Agent Runtime verwenden, benötigt der Reasoning Engine Service Agent auch diese Berechtigungen, wie unter Agent Runtime-Traffic über das Agent Gateway weiterleiten beschrieben.

gcloud

Erstellen Sie die erforderlichen Model Armor-Vorlagen.
Wenn sich Ihre Model Armor-Vorlagen in einem anderen Projekt als dem Gateway befinden, müssen Sie dem Agent Gateway-Dienstkonto 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.

Konfigurieren Sie die Autorisierungserweiterung so, dass sie auf Model Armor verweist.

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

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-ma-content-authz-ext \
   --source=ma-content-authz-extension.yaml \
   --location=LOCATION
```

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.
  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 wird auf CONTENT_AUTHZ festgelegt. Das bedeutet, dass der benutzerdefinierte Richtlinienanbieter den Anfrage- und Antwort-Traffic einschließlich des Anfragetexts verarbeitet.
  
  Der Parameter httpRules zeigt, wie Sie CEL-Attribute verwenden, um Bedingungen zu erstellen, die mit dem spezifischen Traffic übereinstimmen, den Sie zur Auswertung an Model Armor weiterleiten möchten. In diesem Beispiel stimmen die Regeln mit allen Traffic-Arten mit den Inhaltstypen application/json oder text/ überein. Wir empfehlen, solche Regeln zu verwenden, um die Model Armor-Bewertung 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 Agent-gRPC-Aufrufe 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 wird auf CONTENT_AUTHZ festgelegt. Das bedeutet, dass der benutzerdefinierte Richtlinienanbieter den Anfrage- und Antwort-Traffic einschließlich des Anfragetexts verarbeitet.
2. Importieren Sie die Autorisierungsrichtlinie in das Projekt. Verwenden Sie den Befehl gcloud beta network-security authz-policies import 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 werden.

Wenn Sie FQDN-Ziele verwenden, verwendet die Erweiterung das HTTP2-Protokoll mit TLS-Verschlüsselung für die Kommunikation mit Endpunkten an Port 443. Die Erweiterung validiert das Serverzertifikat jedoch nicht. 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.

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
```

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

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

Autorisierungsrichtlinie erstellen

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 über das Profil REQUEST_AUTHZ verknüpft ist, wie in diesem Beispiel gezeigt, das Gateway die Erweiterung nur aufruft, wenn Anfrageheader eingehen. Der Anfrage- und Antworttext sowie die Antwortheader sind für die Autorisierungserweiterung nicht sichtbar.

IAP-Autorisierung mit Model Armor-Schutzmaßnahmen 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 zentrales System zur Autorisierung von Anfragen und Model Armor für KI-Schutzmaßnahmen verwendet. Wie in den vorherigen Beispielen gezeigt, können Sie diese durch Dienst-Extensions ersetzen, um Ihre eigenen benutzerdefinierten Lösungen zu verwenden.

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

Definieren Sie die Autorisierungserweiterung.

cat >iap-extension.yaml <<EOF
name: iap-extension
service: iap.googleapis.com
failOpen: true
timeout: 1s
EOF

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.

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

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-Gateways.

Autorisierungsrichtlinie erstellen

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

Konfigurieren Sie eine CONTENT_AUTHZ-Autorisierungserweiterung, die an Model Armor delegiert, und eine Autorisierungsrichtlinie, die auf die Erweiterung verweist.

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 Anfrageschablone.

Erstellen Sie die Autorisierungserweiterung.

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

Konfigurieren Sie die CONTENT_AUTHZ-Autorisierungsrichtlinie, die an die Erweiterung delegiert wird.

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

Autorisierungsrichtlinie erstellen

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 Antwortheadern, Text und Trailern. Wenn Ihre auf ext_proc basierende 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 einzelne 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 auf Grundlage von 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 anhand von 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.

Konfigurieren Sie die Autorisierungsrichtlinie.

ALLOW-Richtlinienbeispiel

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

Wenn Sie eine ALLOW-Richtlinie schreiben, müssen Sie baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS angeben, damit nicht zugriffsspezifische MCP-RPCs wie „initialize“, „logging“, „completion“, „notifications“ und „ping“ weiterhin funktionieren. Andernfalls kann keine MCP-Sitzung hergestellt 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

DENY-Richtlinienbeispiel

In diesem Beispiel wird der Zugriff auf alle Prompts/ Methoden auf einem MCP-Server hinter einem Agent Gateway verboten.

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

Autorisierungsrichtlinie erstellen
```
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 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 FULL_DUPLEX_STREAMED-Modus für Körperereignisse unterstützen.
Wenn Sie mehrere benutzerdefinierte Autorisierungsrichtlinien konfigurieren, die dasselbe Profil verwenden, ist die Ausführungsreihenfolge nicht garantiert.

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

Informationen zu Einschränkungen, die für alle Erweiterungen gelten, finden Sie unter Einschränkungen von Erweiterungen.
Informationen zu den Einschränkungen für Callouts finden Sie unter Einschränkungen für Callouts.

Nächste Schritte

Leitfaden

Monitor Agent Gateway

Informationen zum Überwachen des KI-Agenten-Gateways

Autorisierung mit Service Extensions delegieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Autorisierungserweiterungen

Hinweis

Autorisierungsrichtlinien mit Erweiterungen konfigurieren

Autorisierung an IAP delegieren

Autorisierung an Model Armor delegieren

Console

gcloud

Agent zu beliebigem Ziel

Client zu Agent

Autorisierung an benutzerdefinierte Autorisierungserweiterungen delegieren

IAP-Autorisierung mit Model Armor-Schutzmaßnahmen kombinieren

Autorisierung auf Grundlage von MCP-Protokollattributen

Beschränkungen

Nächste Schritte

Monitor Agent Gateway

Autorisierung mit Service Extensions delegieren