Eine Autorisierungsrichtlinie (AuthzPolicy), die auf die Weiterleitungsregel von Application Load Balancern angewendet wird, definiert Regeln, die die Quelle des eingehenden Traffics und die für diese Quelle zulässigen oder eingeschränkten Vorgänge angeben.
Außerdem werden in der Autorisierungsrichtlinie die Bedingungen beschrieben, unter denen eine Regel angewendet wird, und eine Aktion angegeben, mit der der Traffic zugelassen, abgelehnt oder weiter ausgewertet wird.
Mit Autorisierungsrichtlinien können Sie Zugriffssteuerungsprüfungen für eingehenden Traffic an Application Load Balancer einrichten. Anfragen, die diese Prüfungen bestehen, werden an Backend-Dienste weitergeleitet. Anfragen, die diese Prüfungen nicht bestehen, werden mit einer nicht autorisierten Antwort beendet.
Autorisierungsrichtlinien können für die Weiterleitungsregel aller Application Load Balancer mit einem Load-Balancing-Schema von EXTERNAL_MANAGED oder INTERNAL_MANAGED konfiguriert werden.
Die folgenden Application Load Balancer unterstützen Autorisierungsrichtlinien:
- Globale externe Application Load Balancer
Regionale externe Application Load Balancer
Regionale interne Application Load Balancer
- Regionsübergreifende interne Application Load Balancer
In Application Load Balancern werden Autorisierungsrichtlinien nach der Auswertung von Routenerweiterungen, Netzwerksicherheitsrichtlinien (die von Google Cloud Armor ausgewertet werden), CORS-Richtlinien (Cross-Origin Resource Sharing) und IAP-Richtlinien (Identity-Aware Proxy) aufgerufen, aber vor der Ausführung von Traffic-Management-Aktionen.
Weitere Informationen dazu, wann Autorisierungsrichtlinien im Anfrageverarbeitungspfad aufgerufen werden, finden Sie unter Erweiterungspunkte im Load-Balancing-Datenpfad.
Wenn Sie Autorisierungsrichtlinien für Dienste verwenden möchten, die mit Cloud Service Mesh bereitgestellt werden, lesen Sie den Abschnitt Dienstsicherheit mit Envoy einrichten.
Regeln für Autorisierungsrichtlinien
Eine Autorisierungsrichtlinie besteht aus einer Liste von HTTP-Regeln, die mit der eingehenden Anfrage abgeglichen werden.
Für eine Autorisierungsrichtlinie mit der Aktion ALLOW oder DENY werden mit einer HTTP-Regel (AuthzRule) die Bedingungen definiert, die bestimmen, ob Traffic den Load Balancer passieren darf. Es ist mindestens eine HTTP-Regel erforderlich.
Bei einer Autorisierungsrichtlinie mit der Aktion CUSTOM werden mit einer HTTP-Regel (AuthzRule) die Bedingungen definiert, die bestimmen, ob der Traffic zur Autorisierung an den benutzerdefinierten Anbieter delegiert wird. Ein benutzerdefinierter Anbieter ist erforderlich, HTTP-Regeln sind optional.
Ein Richtlinienabgleich erfolgt, wenn mindestens eine HTTP-Regel mit der Anfrage übereinstimmt oder wenn in der Richtlinie keine HTTP-Regeln definiert sind.
Eine HTTP-Regel für eine Autorisierungsrichtlinie besteht aus den folgenden Feldern:
from: Gibt die Identität des Clients an, der durch die Regel zugelassen wird. Die Identität kann aus einem Clientzertifikat in einer mTLS-Verbindung abgeleitet werden oder es kann sich um die Umgebungsidentität handeln, die der Client-VM-Instanz zugewiesen ist, z. B. aus einem Dienstkonto oder einem sicheren Tag.to: Gibt die von der Regel zulässigen Vorgänge an, z. B. die URLs, auf die zugegriffen werden kann, oder die zulässigen HTTP-Methoden.when: Gibt zusätzliche Einschränkungen an, die erfüllt sein müssen. Sie können CEL-Ausdrücke verwenden, um die Einschränkungen zu definieren.
Aktionen für Autorisierungsrichtlinien
Bei der Auswertung einer Anfrage wird in einer Autorisierungsrichtlinie die Aktion (AuthzAction) angegeben, die auf die Anfrage angewendet werden soll. Eine Autorisierungsrichtlinie muss mindestens eine Aktion haben, die eine der folgenden sein kann:
ALLOW: Die Anfrage wird an das Backend weitergeleitet, wenn sie mit einer der Regeln übereinstimmt, die in einerALLOW-Richtlinie angegeben sind. WennALLOW-Richtlinien vorhanden sind, aber keine Übereinstimmung gefunden wird, wird die Anfrage abgelehnt. Mit anderen Worten: Die Anfrage wird abgelehnt, wenn keine der konfigurierten Autorisierungsrichtlinien mit einerALLOW-Aktion der Anfrage entspricht. In Cloud Logging wird diese Aktion alsdenied_as_no_allow_policies_matched_requestprotokolliert.Damit eine
ALLOW-Aktion angewendet werden kann, benötigen Sie mindestens eine HTTP-Regel.DENY: Die Anfrage wird abgelehnt, wenn sie mit einer der Regeln übereinstimmt, die in einerDENY-Richtlinie angegeben sind. WennDENY-Richtlinien vorhanden sind, aber keine Übereinstimmung gefunden wird, ist die Anfrage zulässig. Mit anderen Worten: Die Anfrage ist zulässig, wenn keine der konfigurierten Autorisierungsrichtlinien mit einerDENY-Aktion mit der Anfrage übereinstimmt. In Cloud Logging wird diese Aktion alsallowed_as_no_deny_policies_matched_requestprotokolliert.Damit eine
DENY-Aktion angewendet werden kann, benötigen Sie mindestens eine HTTP-Regel.CUSTOM: Die Autorisierungsentscheidung wird an einen benutzerdefinierten Autorisierungsanbieter wie IAP oder Diensterweiterungen delegiert. Weitere Informationen finden Sie unter Autorisierungsrichtlinien verwenden, um Autorisierungsentscheidungen zu delegieren.Wenn für eine
CUSTOM-Richtlinie HTTP-Regeln konfiguriert sind, muss die Anfrage mit den HTTP-Regeln übereinstimmen, damit der benutzerdefinierte Anbieter aufgerufen wird. Wenn jedoch keine HTTP-Regeln definiert sind, wird die Autorisierungsentscheidung in der Autorisierungsrichtlinie immer an einen benutzerdefinierten Autorisierungsanbieter delegiert. Weitere Informationen finden Sie im folgenden Beispiel, in dem keine HTTP-Regeln definiert sind und die Autorisierungsrichtlinie die Autorisierungsentscheidung an einen IAP delegiert:
Reihenfolge der Auswertung von Autorisierungsrichtlinien
Eine Autorisierungsrichtlinie unterstützt CUSTOM-, DENY- und ALLOW-Richtlinien für die Zugriffssteuerung. Wenn einer einzelnen Ressource mehrere Autorisierungsrichtlinien zugeordnet sind, wird zuerst die CUSTOM-Richtlinie, dann die DENY-Richtlinie und schließlich die ALLOW-Richtlinie ausgewertet. Die Bewertung erfolgt nach den folgenden Regeln:
Wenn eine
CUSTOM-Richtlinie mit der Anfrage übereinstimmt, wird dieCUSTOM-Richtlinie mit den benutzerdefinierten Autorisierungsanbietern ausgewertet. Die Anfrage wird abgelehnt, wenn der Anbieter sie ablehnt.DENY- oderALLOW-Richtlinien werden nicht ausgewertet, auch wenn sie konfiguriert sind.Wenn
DENY-Richtlinien vorhanden sind, die der Anfrage entsprechen, wird die Anfrage abgelehnt. AlleALLOW-Richtlinien werden nicht ausgewertet, auch wenn sie konfiguriert sind.Wenn keine
ALLOW-Richtlinien vorhanden sind, ist die Anfrage zulässig.Wenn eine der
ALLOW-Richtlinien mit der Anfrage übereinstimmt, lassen Sie die Anfrage zu.Wenn
ALLOW-Richtlinien vorhanden sind, aber keine Übereinstimmung gefunden wird, wird die Anfrage abgelehnt. Mit anderen Worten: Die Anfrage wird standardmäßig abgelehnt, wenn keine der konfiguriertenAuthzPoliciesmit der AktionALLOWmit der Anfrage übereinstimmt.
Autorisierungsentscheidungen mithilfe von Autorisierungsrichtlinien delegieren
Bei komplexen Autorisierungsentscheidungen, die nicht mit der Autorisierungsrichtlinie ausgedrückt werden können, delegieren Sie die Autorisierungsentscheidung an benutzerdefinierte Autorisierungsanbieter wie Identity-Aware Proxy (IAP) oder erstellen Sie Ihre eigene Autorisierungserweiterung mit Diensterweiterungen. Dies ist nützlich, wenn Sie Ihre lokale Autorisierungs-Engine oder externe Identitätsanbieter über IAP verwenden möchten.
IAP: Konfigurieren Sie IAP, um den Zugriff auf Anwendungen hinter Weiterleitungsregeln für Application Load Balancer zu steuern. IAP prüft die Nutzeridentität und den Kontext, um den Zugriff zu bestimmen. Außerdem kann IAP IAM-Dienstkontotokens (Identity and Access Management) authentifizieren und IAM-Richtlinien auswerten, um den Zugriff auf Backend-Buckets zu schützen, die über den Application Load Balancer freigegeben werden. Weitere Informationen finden Sie unter Autorisierung an IAP und IAM delegieren.
In den folgenden Fällen kann es sinnvoll sein, die Authentifizierung an IAP und IAM zu delegieren:
- IAM für die Berechtigungsverwaltung verwenden
- Implementieren Sie kontextsensitiven Zugriff.
- Verwenden Sie die browserbasierte Authentifizierung für Webanwendungen, die eine interaktive Authentifizierung erfordern.
Diensterweiterungen: Autorisierungsentscheidungen an Ihre benutzerdefinierte Autorisierungs-Engine delegieren, die auf Google Cloud -VM-Instanzen oder lokal ausgeführt wird. Dies bietet Flexibilität für komplexe Autorisierungsrichtlinien, die nicht von integrierten Richtlinien abgedeckt werden. Weitere Informationen finden Sie unter Autorisierungserweiterung konfigurieren.
Autorisierungsrichtlinie basierend auf Dienstkonten oder Tags
Sie können Attribute wie Dienstkonten oder Tags verwenden, um die Quelle des Traffics für interne Application Load Balancer zu identifizieren.
Bei internen Application Load Balancern können Sie Autorisierungsrichtlinien basierend auf Dienstkonten oder Tags anwenden, die an Google Cloud -Ressourcen angehängt sind. Traffic, der von diesen Google Cloud Ressourcen stammt und mit einem bestimmten Dienstkonto oder Tag verknüpft ist, kann entweder zugelassen, abgelehnt oder an einen externen Dienst delegiert werden.
In den folgenden Tabellen sind die Quellressourcen und verschiedenen VPC-Architekturen (Virtual Private Cloud) aufgeführt, die die Verwendung von Dienstkonten und Tags unterstützen.
| Quelle | Support für Dienstkonten | Tag-Unterstützung |
|---|---|---|
| VM | ||
| GKE-Knoten | ||
| GKE-Container | * | * |
| Direct VPC für Cloud Run | * | |
| Connector für serverlosen VPC-Zugriff | † | † |
| Cloud VPN | * | * |
| Cloud Interconnect lokal | * | * |
| Application Load Balancer | ||
| Netzwerk-Load-Balancer |
* Wird von Google Cloudnicht unterstützt.
† Die Quell-IP-Adresse ist eindeutig und kann stattdessen verwendet werden.
| VPC | VPC-Architektur | Support |
|---|---|---|
| Innerhalb von VPC | Projektübergreifend (freigegebene VPC) | |
| Innerhalb von VPC | Regionenübergreifend | |
| VPC-übergreifend | Cross-Peering-Link (Peering-VPC) | |
| VPC-übergreifend | Cross Private Service Connect | |
| VPC-übergreifend | Cross Network Connectivity Center-Spokes |
Weitere Informationen zum Einrichten einer Autorisierungsrichtlinie, die auf Dienstkonten und Tags basiert, die an eine Google Cloud VM-Ressource angehängt sind, finden Sie unter Autorisierungsrichtlinie basierend auf Dienstkonten oder Tags.
Kontingente
Informationen zu Kontingenten für Autorisierungsrichtlinien finden Sie unter Kontingente und Limits für Autorisierungsrichtlinien.
Preise
Autorisierungsrichtlinien werden während des Vorschauzeitraums nicht berechnet. Bei der Verwendung von Google Cloud Load-Balancern fallen jedoch Netzwerkgebühren an. Preisinformationen finden Sie unter Preise.