Übersicht über Autorisierungsrichtlinien

Eine Autorisierungsrichtlinie (AuthzPolicy), die auf die Weiterleitungsregel von Application Load Balancern angewendet wird, definiert Regeln für die Quelle des eingehenden Traffics und die für diese Quelle zulässigen oder eingeschränkten Vorgänge. Außerdem werden in der Autorisierungsrichtlinie die Bedingungen beschrieben, unter denen eine Regel gilt, und eine Aktion angegeben, um den Traffic entweder zuzulassen, abzulehnen oder weiter zu prüfen.

Mit Autorisierungsrichtlinien können Sie Zugriffssteuerungsprüfungen für eingehenden Traffic an Application Load Balancer einrichten. Anfragen, die diese Prüfungen bestehen, werden an Back-End-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

Bei Application Load Balancern werden Autorisierungsrichtlinien nach der Auswertung von Routenerweiterungen, Netzwerksicherheitsrichtlinien (von Google Cloud Armor ausgewertet), 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 Pfad zur Anfrageverarbeitung aufgerufen werden, finden Sie unter Erweiterungspunkte im Load Balancing-Datenpfad.

Informationen zum Verwenden von Autorisierungsrichtlinien für Dienste, die mit Cloud Service Mesh bereitgestellt werden, finden Sie unter Dienstsicherheit mit Envoy einrichten.

Regeln für Autorisierungsrichtlinien

Eine Autorisierungsrichtlinie besteht aus einer Liste von HTTP-Regeln, die mit der eingehenden Anfrage abgeglichen werden.

Bei einer Autorisierungsrichtlinie mit einer ALLOW- oder DENY-Aktion werden in einer HTTP-Regel (AuthzRule) die Bedingungen festgelegt, die bestimmen, ob Traffic den Load Balancer passieren darf. Es ist mindestens eine HTTP-Regel erforderlich.

Bei einer Autorisierungsrichtlinie mit der Aktion CUSTOM werden in einer HTTP-Regel (AuthzRule) die Bedingungen definiert, die festlegen, ob Traffic zur Autorisierung an den benutzerdefinierten Anbieter delegiert wird. Ein benutzerdefinierter Anbieter ist erforderlich, während HTTP-Regeln optional sind.

Eine Richtlinienübereinstimmung tritt auf, wenn mindestens eine HTTP-Regel mit der Anfrage übereinstimmt oder wenn in der Richtlinie keine HTTP-Regeln definiert sind.

Eine HTTP-Regel für Autorisierungsrichtlinien besteht aus den folgenden Feldern:

  • from: Gibt die Identität des Clients an, die gemäß der Regel zulässig ist. 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 werden müssen. Sie können Common Expression Language (CEL)-Ausdrücke verwenden, um die Einschränkungen zu definieren.

Aktionen für Autorisierungsrichtlinien

Bei der Auswertung einer Anfrage gibt eine Autorisierungsrichtlinie die Aktion (AuthzAction) an, die auf die Anfrage angewendet werden soll. Eine Autorisierungsrichtlinie muss mindestens eine Aktion haben. Folgende Aktionen sind möglich:

  • ALLOW: Die Anfrage wird an das Backend weitergeleitet, wenn sie mit einer der Regeln in einer ALLOW-Richtlinie übereinstimmt. Wenn ALLOW-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 einer ALLOW-Aktion mit der Anfrage übereinstimmt. In Cloud Logging wird diese Aktion als denied_as_no_allow_policies_matched_request protokolliert.

    Damit eine ALLOW-Aktion angewendet werden kann, ist mindestens eine HTTP-Regel erforderlich.

  • DENY: Die Anfrage wird abgelehnt, wenn sie mit einer der Regeln in einer DENY-Richtlinie übereinstimmt. Wenn DENY-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 einer DENY-Aktion mit der Anfrage übereinstimmt. In Cloud Logging wird diese Aktion als allowed_as_no_deny_policies_matched_request protokolliert.

    Damit eine DENY-Aktion angewendet werden kann, ist mindestens eine HTTP-Regel erforderlich.

  • CUSTOM: Delegiert die Autorisierungsentscheidung an einen benutzerdefinierten Autorisierungsanbieter, z. B. IAP oder Diensterweiterungen. Weitere Informationen finden Sie unter Autorisierungsentscheidungen mithilfe von Autorisierungsrichtlinien 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, delegiert die Autorisierungsrichtlinie die Autorisierungsentscheidung immer an einen benutzerdefinierten Autorisierungsanbieter. Weitere Informationen finden Sie im folgenden Beispiel, in dem keine HTTP-Regeln definiert sind und die Autorisierungsrichtlinie die Autorisierungsentscheidung an einen IAP delegiert:

    Autorisierungsrichtlinie erstellen und IAP aktivieren

Reihenfolge der Auswertung von Autorisierungsrichtlinien

Eine Autorisierungsrichtlinie unterstützt CUSTOM-, DENY- und ALLOW-Richtlinien für die Zugriffssteuerung. Wenn einer einzelnen Ressource mehrere Autorisierungsrichtlinien zugewiesen sind, wird zuerst die CUSTOM-Richtlinie, dann die DENY-Richtlinie und schließlich die ALLOW-Richtlinie ausgewertet. Die Bewertung erfolgt anhand der folgenden Regeln:

  1. Wenn eine CUSTOM-Richtlinie mit der Anfrage übereinstimmt, wird die CUSTOM-Richtlinie mithilfe der benutzerdefinierten Autorisierungsanbieter ausgewertet. Wenn der Anbieter die Anfrage ablehnt, wird sie abgelehnt. DENY- oder ALLOW-Richtlinien werden nicht ausgewertet, auch wenn sie konfiguriert sind.

  2. Wenn es DENY-Richtlinien gibt, die mit der Anfrage übereinstimmen, wird die Anfrage abgelehnt. ALLOW-Richtlinien werden nicht ausgewertet, auch wenn sie konfiguriert sind.

  3. Wenn keine ALLOW-Richtlinien vorhanden sind, wird die Anfrage zugelassen.

  4. Wenn eine der ALLOW-Richtlinien mit der Anfrage übereinstimmt, erlauben Sie die Anfrage.

  5. 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 konfigurierten AuthzPolicies-Elemente mit der Aktion ALLOW mit der Anfrage übereinstimmt.

Autorisierungsrichtlinien zum Delegieren von Autorisierungsentscheidungen verwenden

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 eine eigene Autorisierungserweiterung, die mit Diensterweiterungen erstellt wurde. 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 zu steuern, die sich hinter den Weiterleitungsregeln des Application Load Balancers befinden. 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 können Sie die Authentifizierung an IAP und IAM delegieren:

    • Verwenden Sie IAM für die Berechtigungsverwaltung.
    • Implementieren Sie kontextsensitiven Zugriff.
    • Verwenden Sie die browserbasierte Authentifizierung für Webanwendungen, die eine interaktive Authentifizierung erfordern.

  • Diensterweiterungen: Delegieren Sie Autorisierungsentscheidungen an Ihre benutzerdefinierte Autorisierungs-Engine, die auf Google Cloud VM-Instanzen oder lokal ausgeführt wird. Dies bietet Flexibilität für komplexe Autorisierungsrichtlinien, die nicht durch vordefinierte Richtlinien abgedeckt sind. 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 mit Google Cloud -Ressourcen verknüpft sind. Traffic, der von diesen Google Cloud Ressourcen stammt, die mit einem bestimmten Dienstkonto oder Tag verknüpft sind, kann entweder zugelassen, abgelehnt oder an einen externen Dienst delegiert werden.

In den folgenden Tabellen sind die Quellressourcen und die verschiedenen VPC-Architekturen (Virtual Private Cloud) aufgeführt, die die Verwendung von Dienstkonten und Tags unterstützen.

Quelle Unterstützung 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 on Premises * *
Application Load Balancer
Netzwerk-Load-Balancer

* Von Google Cloudnicht unterstützt.

† Die Quell-IP-Adresse ist eindeutig und kann stattdessen verwendet werden.

VPC VPC-Architektur Support
Innerhalb der VPC Projektübergreifend (freigegebene VPC)
Innerhalb der VPC Regionsübergreifend
VPC-übergreifender Zugriff Peering-Link (Peer-VPC)
VPC-übergreifender Zugriff Private Service Connect-übergreifender Zugriff
VPC-übergreifender Zugriff Network Connectivity Center-Spokes kreuzen

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 auf Dienstkonten oder Tags basierend.

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 Load Balancern fallen jedoch Netzwerkgebühren an. Google Cloud Preisinformationen finden Sie unter Preise.

Nächste Schritte