Übersicht über Autorisierungsrichtlinien

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 definiert eine HTTP-Regel (AuthzRule) die Bedingungen, 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 einer ALLOW-Richtlinie angegeben sind. 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 der Anfrage entspricht. In Cloud Logging wird diese Aktion als denied_as_no_allow_policies_matched_request protokolliert.

    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 einer DENY-Richtlinie angegeben sind. 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, 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:

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

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

  2. Wenn DENY-Richtlinien vorhanden sind, die der Anfrage entsprechen, wird die Anfrage abgelehnt. Alle ALLOW-Richtlinien werden nicht ausgewertet, auch wenn sie konfiguriert sind.

  3. Wenn keine ALLOW-Richtlinien vorhanden sind, ist die Anfrage zulässig.

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

  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 mit der Aktion ALLOW mit 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.

Hauptkontobasierte Autorisierungsrichtlinie

Um die Quelle des Traffics mit hoher Granularität zu ermitteln, können Sie Autorisierungsrichtlinien basierend auf Identitäten konfigurieren, die aus dem Zertifikat eines Clients abgeleitet werden. Für diese Methode muss Frontend-mTLS für den Load Balancer aktiviert sein. Außerdem werden die folgenden Zertifikatattribute als Hauptselektor zur Identifizierung verwendet:

  • SANs des Clientzertifikat-URI (CLIENT_CERT_URI_SAN)
  • SANs für DNS-Namen von Clientzertifikaten (CLIENT_CERT_DNS_NAME_SAN)
  • Allgemeiner Name des Clientzertifikats (CLIENT_CERT_COMMON_NAME)

Wenn kein Prinzipal-Selektor für die Identifizierung angegeben ist, wird CLIENT_CERT_URI_SAN als Standard-Prinzipal-Selektor verwendet. Das bedeutet, dass die URI-SANs des Clientzertifikats bei Autorisierungsentscheidungen berücksichtigt werden.

Damit die prinzipalbasierte Autorisierung funktioniert, müssen die folgenden Bedingungen erfüllt sein:

  • Frontend-mTLS muss aktiviert sein. Wenn Frontend-mTLS nicht aktiviert ist, legt der Client kein Zertifikat vor. Daher finden prinzipalbasierte Regeln in der Autorisierungsrichtlinie keine Zertifikatsinformationen, die ausgewertet werden können. Wenn beispielsweise eine Regel, die CLIENT_CERT_URI_SAN prüft, einen leeren Wert sieht,

  • Es muss ein gültiges Clientzertifikat vorhanden sein. Auch wenn mTLS aktiviert ist, wird kein Clientzertifikat für die Autorisierung verwendet, wenn die Verbindung mit einem fehlenden oder ungültigen Zertifikat hergestellt wurde. Dieses Szenario tritt auf, wenn der mTLS-Clientvalidierungsmodus auf den permissiven Modus ALLOW_INVALID_OR_MISSING_CLIENT_CERT eingestellt ist. Auch in diesem Fall finden alle prinzipalbasierten Regeln in der Autorisierungsrichtlinie keine Zertifikatsinformationen, die ausgewertet werden können. Wenn beispielsweise eine Regel, die CLIENT_CERT_URI_SAN prüft, einen leeren Wert sieht,

Auswirkungen von Größenbeschränkungen für Attribute

Autorisierungsentscheidungen hängen von der Größe der Clientzertifikatattribute ab. Eine Anfrage wird abgelehnt, wenn ein Attribut sein Größenlimit überschreitet und die Richtlinie so konfiguriert ist, dass dieses Attribut validiert wird.

Eine Ablehnung kann unter den folgenden Bedingungen erfolgen:

  • Die Richtlinie wird anhand von CLIENT_CERT_URI_SAN validiert und die URI-SANs des Zertifikats überschreiten die Größenbeschränkung.
  • Die Richtlinie wird anhand von CLIENT_CERT_DNS_NAME_SAN validiert und die DNS-Name-SANs des Zertifikats überschreiten die Größenbeschränkung.
  • Die Richtlinie wird anhand von CLIENT_CERT_COMMON_NAME validiert und das Betreff-Feld des Zertifikats (das den allgemeinen Namen enthält) überschreitet die Größenbeschränkung.

Wenn das Attribut eines Zertifikats das Größenlimit überschreitet, aber nicht explizit vom Prinzipal-Selektor der Richtlinie validiert wird, wird die Anfrage weiterhin anhand der konfigurierten Prinzipalregeln ausgewertet. Wenn beispielsweise eine Richtlinie so konfiguriert ist, dass nur CLIENT_CERT_DNS_NAME_SAN validiert wird, wird eine Anfrage von einem Client mit zu großen URI-SANs aus diesem Grund nicht abgelehnt. Die Richtlinie bewertet die Anfrage anhand der SANs des DNS-Namens.

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.

Nächste Schritte