Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Autorisierung mit Service Extensions delegieren

Auf dieser Seite erfahren Sie, wie Sie die Autorisierung für das KI-Agenten-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 über den vom KI-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 Ihre Anwendungspayloads 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 KI-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 KI-Agenten-Gateway-Bereitstellung geleitet werden. Sie führt einen gRPC-Aufruf in Echtzeit an einen externen Dienst aus, den Sie verwalten, damit Sie Traffic prüfen, ändern oder sogar blockieren können, bevor er sein Ziel erreicht.

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 KI-Agenten-Gateway ist bereitgestellt. Weitere Informationen finden Sie unter KI-Agenten-Gateway konfigurieren.
Sie benötigen die IAM-Berechtigung agentGateway.use für die bereitgestellte KI-Agenten-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 Anfrageautorisierung konfigurieren, um Zugriffsentscheidungen für Autorisierungsrichtlinien an IAP zu delegieren.

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

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.
Unter KI-Agenten-Gateway im Modus „KI-Agent zu überall“ (ausgehend) konfigurieren erfahren Sie, wie Sie IAP aktivieren, während Sie das KI-Agenten-Gateway erstellen (mit dem Parameter Zugriffsautorisierung).

Für IAP müssen Ihre Agenten 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. 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 iamEnforcementMode im Block metadata angeben.
```
cat >iap-request-authz-extension.yaml <<EOF
name: my-iap-request-authz-ext
service: iap.googleapis.com
failOpen: true
timeout: 1s
metadata:
  iapPolicyVersion: "V1"
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 iamEnforcementMode im Block metadata 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:
  iapPolicyVersion: "V1"
  iamEnforcementMode: "DRY_RUN"
EOF
```
  Entfernen Sie das Feld iamEnforcementMode: "DRY_RUN" aus dem Block metadata wenn Sie Richtlinien erzwingen möchten.
2. Importieren Sie die Autorisierungserweiterung. Verwenden Sie den gcloud service-extensions authz-extensions import Befehl mit den folgenden Beispielwerten.
```
gcloud 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 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.

Importieren Sie die Autorisierungsrichtlinie in das Projekt. Verwenden Sie den gcloud 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 KI-Agenten-Gateway konfigurieren.

Console

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

Erstellen Sie die erforderlichen Model Armor-Vorlagen.
Unter KI-Agenten-Gateway konfigurieren erfahren Sie, wie Sie Model Armor aktivieren, während Sie das KI-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 überall“ unterstützt.
Wenn Sie Model Armor verwenden, müssen Sie dem Dienstkonto des KI-Agenten-Gateways die Berechtigungen erteilen, die für die Verwendung der Model Armor-Vorlagen erforderlich sind. 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.

Sie müssen diesen Schritt auch ausführen, wenn sich sowohl das Gateway als auch die Vorlagen im selben Projekt befinden. Erteilen Sie die folgenden Rollen:
- 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 Agent Runtime verwenden, benötigt der Reasoning Engine-Dienst-Agent auch diese Berechtigungen, wie unter Agent Runtime-Traffic über das KI-Agenten-Gateway leiten beschrieben.

gcloud

Erstellen Sie die erforderlichen Model Armor-Vorlagen.
Wenn Sie Model Armor verwenden, müssen Sie dem Dienstkonto des KI-Agenten-Gateways die Berechtigungen erteilen, die für die Verwendung der Model Armor-Vorlagen erforderlich sind. 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.

Sie müssen diesen Schritt auch ausführen, wenn sich sowohl das Gateway als auch die Vorlagen im selben Projekt befinden. Erteilen Sie die folgenden Rollen:
- 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, die 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 service-extensions authz-extensions import Befehl mit den folgenden Beispiel werten.
```
gcloud 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 KI-Agenten-Gateway verknüpft.
  KI-Agent zu überall
  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 Anfrage- 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 Anfrage- und Antworttraffic einschließlich des Anfragetexts verarbeitet.
2. Importieren Sie die Autorisierungsrichtlinie in das Projekt. Verwenden Sie den gcloud network-security authz-policies import Befehl mit den folgenden Beispielwerten.
```
gcloud 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 KI-Agenten-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

Erstellen Sie die Autorisierungsrichtlinie.

gcloud 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 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 Anfrageautorisierung und Model Armor für KI-Leitplanken verwendet. Wie in den vorherigen Beispielen gezeigt, können Sie diese jeweils durch Service 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. Das Feld iapPolicyVersion unter metadata ist obligatorisch und muss auf "V1" gesetzt sein.

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

Erstellen Sie die Autorisierungserweiterung.

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

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

Erstellen Sie die Autorisierungsrichtlinie.

gcloud 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 Anfragevorlage.

Erstellen Sie die Autorisierungserweiterung.

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

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

Erstellen Sie die Autorisierungsrichtlinie.

gcloud 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 KI-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.

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

Erstellen Sie die Autorisierungsrichtlinie.
```
gcloud 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:

Für KI-Agenten-Gateways im Modus „KI-Agent zu überall“ (ausgehend) können Sie unabhängig vom Richtlinienprofil maximal vier benutzerdefinierte Autorisierungsrichtlinien pro Gateway konfigurieren.
Für KI-Agenten-Gateways im Modus „Client zu Agent“ (eingehend) können Sie maximal eine CONTENT_AUTHZ-Richtlinie konfigurieren. Wir empfehlen dringend, Model Armor zu verwenden, um sich vor Prompt-Injection-Angriffen zu schützen. Wenn Sie stattdessen eine Semantic Governance Policy-Erweiterung verwenden möchten, muss Model Armor für das Gateway deaktiviert sein. Andere Arten von Service Extensions werden für eingehenden Traffic nicht unterstützt.
Wenn Sie benutzerdefinierte Autorisierungserweiterungen mit dem CONTENT_AUTHZ-Profil 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:

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

Nächste Schritte

Codelab

Autorisierung mit Service Extensions delegieren

Autorisierungserweiterungen

Hinweis

Autorisierungsrichtlinien mit Erweiterungen konfigurieren

Autorisierung an IAP delegieren

Autorisierung an Model Armor delegieren

Console

gcloud

KI-Agent zu überall

Client zu Agent

Autorisierung an benutzerdefinierte Autorisierungserweiterungen delegieren

IAP-Autorisierung mit Model Armor-Leitplanken kombinieren

Autorisierung basierend auf MCP-Protokollattributen

Beschränkungen

Nächste Schritte

Codelab: Agentische Arbeitslasten mit der Agent Platform verwalten

KI-Agenten-Gateway überwachen

Fehlerbehebung beim KI-Agenten-Gateway

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

KI-Agent zu überall

Client zu Agent

Autorisierung an benutzerdefinierte Autorisierungserweiterungen delegieren

IAP-Autorisierung mit Model Armor-Leitplanken kombinieren

Autorisierung basierend auf MCP-Protokollattributen

Beschränkungen

Nächste Schritte

Codelab: Agentische Arbeitslasten mit der Agent Platform verwalten

KI-Agenten-Gateway überwachen

Fehlerbehebung beim KI-Agenten-Gateway

Autorisierung mit Service Extensions delegieren