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.usefü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:
- Erstellen Sie die erforderlichen IAM-Ausgangsrichtlinien für Ihre Agenten und Tools. Weitere Informationen finden Sie unter IAM-Agent-Richtlinien erstellen.
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
Konfigurieren Sie die Autorisierungserweiterung so, dass sie auf IAP verweist.
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 EOFWenn Sie die Erweiterung im reinen Auditmodus bereitstellen möchten, um die Autorisierungsrichtlinie zu testen, ohne sie zu erzwingen, können Sie das Feld
DRY_RUNangeben. 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 ' EOFImportieren Sie die Autorisierungserweiterung. Verwenden Sie den
gcloud beta service-extensions authz-extensions importBefehl 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-authz-request-extmit 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" EOFErsetzen Sie
PROJECT_IDdurch Ihre Projekt-ID.Importieren Sie die Autorisierungsrichtlinie in das Projekt. Verwenden Sie den
gcloud beta network-security authz-policies importBefehl 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:
Erstellen Sie die erforderlichen Model Armor-Vorlagen.
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.
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.calloutUserundroles/serviceusage.serviceUsageConsumerim Projekt, das das Gateway enthält. - Die Rolle
roles/modelarmor.userim 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.
- Die Rollen
gcloud
Erstellen Sie die erforderlichen Model Armor-Vorlagen.
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.calloutUserundroles/serviceusage.serviceUsageConsumerim Projekt, das das Gateway enthält. - Die Rolle
roles/modelarmor.userim 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.
- Die Rollen
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 EOFImportieren Sie die Autorisierungserweiterung. Verwenden Sie den
gcloud beta service-extensions authz-extensions importBefehl 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
Konfigurieren Sie eine Autorisierungsrichtlinie mit der Erweiterung.
Definieren Sie eine Autorisierungsrichtlinie, die die Erweiterung
my-ma-content-authz-extmit 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" EOFFür Richtlinien zur Inhaltsautorisierung ist der Wert von
policyProfileaufCONTENT_AUTHZfestgelegt. Dieser Wert gibt an, dass der benutzerdefinierte Richtlinienanbieter den Anfrage- und Antworttraffic einschließlich der Textverarbeitung verarbeitet.Importieren Sie die Autorisierungsrichtlinie in das Projekt. Verwenden Sie den
gcloud beta network-security authz-policies importBefehl 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.
Wenn Sie eine Autorisierungserweiterung mit einer Autorisierungsrichtlinie für einen bestimmten FQDN wie
mycustomauthz.internal.netkonfigurieren möchten, geben Sie ihn als Wert fürservicein 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 dasext_authz-Protokoll implementiert.cat >custom-authz-extension.yaml <<EOF name: my-custom-authz-ext service: mycustomauthz.internal.net failOpen: true wireFormat: EXT_AUTHZ_GRPC EOFErstellen 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=LOCATIONNachdem 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 EOFErstellen 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.
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 EOFErstellen Sie die Autorisierungserweiterung.
gcloud beta service-extensions authz-extensions import iap-extension \ --source=iap-extension.yaml \ --location=LOCATION
Ersetzen Sie
LOCATIONdurch 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" EOFErsetzen Sie Folgendes:
PROJECT_ID: Ihre Projekt-ID.LOCATION: Der Standort der Ressourcen.AGENT_GATEWAY_NAME: Der Name des Agent Gateway.
Erstellen Sie die Autorisierungsrichtlinie.
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 EOFErsetzen 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 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.$ 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" EOFErstellen 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.
Konfigurieren Sie die Autorisierungsrichtlinie.
Beispiel für eine
ALLOW-RichtlinieIn 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 SiebaseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODSan, 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 EOFBeispiel für eine
DENY-RichtlinieIn 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 EOFErstellen 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_AUTHZverwenden, müssen diese dasext_proc-Protokoll und den ModusFULL_DUPLEX_STREAMEDfü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.