Autorisierungsrichtlinien für Application Load Balancer einrichten

Auf dieser Seite erfahren Sie, wie Sie Autorisierungsrichtlinien für Application Load Balancer einrichten.

Hinweis

Load-Balancer einrichten

Wenn Sie noch keinen Load Balancer erstellt haben, finden Sie auf den folgenden Seiten Informationen zum Einrichten des gewünschten Application Load Balancers:

Dienstkonten oder Tags für Google Cloud VMs erstellen und anhängen

Für interne Application Load Balancer können Sie Autorisierungsrichtlinien basierend auf Dienstkonten oder Tags anwenden, die mit verschiedenen Google Cloud Ressourcen verknüpft sind.

Im Beispiel in diesem Dokument wird beschrieben, wie Sie eine Autorisierungsrichtlinie basierend auf Dienstkonten oder Tags erstellen, die an Google Cloud VM-Instanzen (virtuelle Maschinen) angehängt sind. Alle Anfragen, die von einer Client-VM stammen, die mit einem bestimmten Dienstkonto oder Tag verknüpft ist, können entweder zugelassen, abgelehnt oder an einen externen Dienst delegiert werden. Ein Beispiel für eine solche Autorisierungsrichtlinie, bei der Dienstkonten und Tags zur Durchsetzung der Zugriffssteuerung verwendet werden, finden Sie im Abschnitt Autorisierungsrichtlinie auf Grundlage von Dienstkonten oder Tags dieses Dokuments.

Die Anwendung von Autorisierungsrichtlinien, die auf Dienstkonten oder Tags basieren, wird für externe Application Load Balancer nicht unterstützt.

Dienstkonten an Client-VMs anhängen

Eine Anleitung zum Anhängen eines Dienstkontos an eine VM-Instanz finden Sie in den folgenden Dokumenten:

Tags an die Instanzgruppenvorlage anhängen

Bevor Sie ein Tag mit der Instanzgruppenvorlage verknüpfen können, müssen Sie einen Tag-Schlüssel und einen Tag-Wert erstellen. Wenn Sie ein Tag erstellen, weisen Sie ihm einen GCE_FIREWALL Zweck zu. Google Cloud Für Netzwerkfunktionen wie sichere Web-Proxys und Autorisierungsrichtlinien ist der GCE_FIREWALL Zweck erforderlich, um das Tag anzuwenden.

Tag-Schlüssel und -Wert erstellen

Zum Erstellen von Tags benötigen Sie die Rolle Tag-Administrator (roles/resourcemanager.tagAdmin).

Console

  1. Rufen Sie in der Google Cloud Console die Seite Tags auf.

    Zu „Tags“

  2. Klicken Sie auf Erstellen.

  3. Geben Sie im Feld Beschreibung des Tag-Schlüssels eine Beschreibung ein.

  4. Klicken Sie das Kästchen Zur Verwendung mit Netzwerk-Firewall an.

  5. Wählen Sie in der Liste Projekt das Google Cloud-Projekt aus, in dem Sie das Tag erstellen möchten.

  6. Wählen Sie im Feld Netzwerk die Option LB_NETWORK aus.

  7. Klicken Sie auf Wert hinzufügen.

  8. Geben Sie im Feld Tag-Wert den Wert TAG_VALUE ein. Der Wert muss eine Zahl sein.

  9. Geben Sie im Feld Tag-Wertbeschreibung eine Beschreibung ein.

  10. Wenn Sie alle Tag-Werte hinzugefügt haben, klicken Sie auf Tag erstellen.

gcloud

  1. Erstellen Sie den Tag-Schlüssel.

    gcloud resource-manager tags keys create TAG_KEY \
    --parent=organizations/ORG_ID \
    --purpose=GCE_FIREWALL \
    --purpose-data=network=LB_NETWORK

    Ersetzen Sie Folgendes:

    • TAG_KEY: Der Name des Tag-Schlüssels.
    • ORG_ID: ID Ihrer Organisation.
    • LB_NETWORK ist der Name des VPC-Netzwerks.

  2. Fügen Sie dem numerischen Tag-Schlüssel den Tag-Wert hinzu.

    gcloud resource-manager tags values create TAG_VALUE \
    --parent=ORG_ID/TAG_KEY

    Ersetzen Sie TAG_VALUE durch einen numerischen Tag-Wert.

Tag an die Instanzgruppenvorlage binden

Tag-Administratoren können Tags an einzelne VM-Instanzen oder die Instanzgruppenvorlage binden und den Tag-Wert an die Backends der VMs oder der Vorlage anhängen.

Zum Binden von Tags benötigen Sie die Rolle Tag-Nutzer (roles/resourcemanager.tagUser).

  1. Legen Sie das Präfix für den vollständigen Namen Ihres Projekts und Ihrer Zone fest:

    FULL_NAME_PREFIX=//compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/instances/

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die Projekt-ID.
    • ZONE: die Zone, in der sich die verwaltete Instanzgruppe befindet.

  2. Rufen Sie die Instanzgruppenvorlage-ID ab:

    TEMPLATE_ID=$(gcloud compute instance-templates describe TEMPLATE_NAME --region=LOCATION --format='value(id)')

    Ersetzen Sie Folgendes:

    • TEMPLATE_NAME: Name der Instanzgruppenvorlage.
    • LOCATION: Ihrer Google Cloud Region.

  3. Verketten Sie die Werte von FULL_NAME_PREFIX und TEMPLATE_ID:

    PARENT="$FULL_NAME_PREFIX$TEMPLATE_ID"
echo $PARENT

  4. Erstellen Sie die Bindungen.

    gcloud resource-manager tags bindings create \
    --location LOCATION \
    --tag-value ORG_ID/TAG_KEY/TAG_VALUE \
    --parent PARENT

    Ersetzen Sie Folgendes:

    • ORG_ID: ID Ihrer Organisation.
    • LOCATION: Ihrer Google Cloud Region.
    • TAG_KEY: der Name des sicheren Tag-Schlüssels.
    • TAG_VALUE: der numerische Tag-Wert.

Autorisierungsrichtlinie erstellen

Wenn Sie eine Autorisierungsrichtlinie erstellen möchten, erstellen Sie eine YAML-Datei, in der das Ziel und die Regeln definiert sind, und importieren Sie die Datei dann mit dem Befehl gcloud beta network-security authz-policies.

In diesem Abschnitt finden Sie eine Anleitung zum Erstellen verschiedener Arten von Autorisierungsrichtlinien, die an die Weiterleitungsregel eines Load Balancers angehängt sind.

Autorisierungsrichtlinie zum Ablehnen von Anfragen

Global und regionsübergreifend

Wenn Sie einen globalen externen oder einen regionenübergreifenden internen Application Load Balancer verwenden, gehen Sie so vor, um die Autorisierungsrichtlinie zu erstellen und zu importieren:

  1. Erstellen Sie die Autorisierungsrichtliniendatei, um bestimmte Anfragen abzulehnen.

    Im folgenden Beispiel wird eine authz-policy-deny.yaml-Datei für die Weiterleitungsregel LB_FORWARDING_RULE am Standort global erstellt. Die Richtlinie verbietet Clients von *.hello.com den Zugriff auf den URL-Pfad /api/payments.

    $ cat >authz-policy-deny.yaml <<EOF
name: my-authz-policy-deny
target:
  loadBalancingScheme: LB_SCHEME
  resources:
  - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules/LB_FORWARDING_RULE"
httpRules:
- from:
    sources:
    - principals:
      - suffix: ".hello.com"
  to:
    operations:
    - paths:
      - prefix: "/api/payments"
action: DENY
EOF

    Ersetzen Sie Folgendes:

    • LB_SCHEME: Ihr Load Balancing-Schema. Legen Sie für globale externe Application Load Balancer das Schema auf EXTERNAL_MANAGED fest. Legen Sie für regionenübergreifende interne Application Load Balancer das Schema auf INTERNAL_MANAGED fest.
    • PROJECT_ID: die ID Ihres Google Cloud-Projekts.
    • LB_FORWARDING_RULE: der Name der Weiterleitungsregel des Load Balancers.

  2. Erstellen Sie die Autorisierungsrichtlinie und importieren Sie die YAML-Datei.

    Mit dem folgenden Beispielbefehl importieren Sie die zuvor erstellte Richtliniendatei und erstellen die Autorisierungsrichtlinien:

    gcloud beta network-security authz-policies import my-authz-policy-deny \
    --source=authz-policy-deny.yaml \
    --location=global

Regional

Wenn Sie einen regionalen externen oder einen regionalen internen Application Load Balancer verwenden, gehen Sie so vor, um die Autorisierungsrichtlinie zu erstellen und zu importieren:

  1. Erstellen Sie die Autorisierungsrichtliniendatei, um bestimmte Anfragen abzulehnen.

    Im folgenden Beispiel wird eine authz-policy-deny.yaml-Datei für die Weiterleitungsregel LB_FORWARDING_RULE in der Region Google Cloud erstellt. Die Richtlinie verbietet Clients mit Identitäten, die mit *.hello.com übereinstimmen, den Zugriff auf den URL-Pfad /api/payments.

    $ cat >authz-policy-deny.yaml <<EOF
name: my-authz-policy-deny
target:
  loadBalancingScheme: LB_SCHEME
  resources:
  - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/LOCATION/forwardingRules/LB_FORWARDING_RULE"
httpRules:
- from:
    sources:
    - principals:
      - suffix: ".hello.com"
  to:
    operations:
    - paths:
      - prefix: "/api/payments"
action: DENY
EOF

    Ersetzen Sie Folgendes:

    • LB_SCHEME: Ihr Load Balancing-Schema. Legen Sie für regionale externe Application Load Balancer das Schema auf EXTERNAL_MANAGED fest. Legen Sie für regionale interne Application Load Balancer das Schema auf INTERNAL_MANAGED fest.
    • PROJECT_ID ist die ID Ihres Google Cloud-Projekts.
    • LOCATION: Ihrer Google Cloud Region.
    • LB_FORWARDING_RULE: der Name der Weiterleitungsregel des Load Balancers.

  2. Erstellen Sie die Autorisierungsrichtlinie und importieren Sie die YAML-Datei.

    Mit dem folgenden Beispielbefehl importieren Sie die zuvor erstellte Richtliniendatei und erstellen die Autorisierungsrichtlinien in der Region LOCATION:

    gcloud beta network-security authz-policies import my-authz-policy-deny \
    --source=authz-policy-deny.yaml \
    --location=LOCATION

Autorisierungsrichtlinie zum Zulassen von Anfragen

Global und regionsübergreifend

Wenn Sie einen globalen externen oder einen regionenübergreifenden internen Application Load Balancer verwenden, gehen Sie so vor, um die Autorisierungsrichtlinie zu erstellen und zu importieren:

  1. Erstellen Sie die Autorisierungsrichtliniendatei, um bestimmte Anfragen zuzulassen.

    Im folgenden Beispiel wird eine authz-policy-allow.yaml-Datei für die Weiterleitungsregel LB_FORWARDING_RULE am Standort global erstellt. Die Richtlinie erlaubt nur Clients von *.example.com, auf den URL-Pfad /api/payments zuzugreifen.

    $ cat >authz-policy-allow.yaml <<EOF
name: my-authz-policy-allow
target:
  loadBalancingScheme: LB_SCHEME
  resources:
  - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules/LB_FORWARDING_RULE"
httpRules:
- from:
  sources:
  - principals:
    - suffix: ".example.com"
  to:
    operations:
    - paths:
      - exact: "/api/payments"
action: ALLOW
EOF

    Ersetzen Sie Folgendes:

    • LB_SCHEME: Ihr Load Balancing-Schema. Legen Sie für globale externe Application Load Balancer das Schema auf EXTERNAL_MANAGED fest. Legen Sie für regionenübergreifende interne Application Load Balancer das Schema auf INTERNAL_MANAGED fest.
    • PROJECT_ID: die ID Ihres Google Cloud-Projekts.
    • LB_FORWARDING_RULE: der Name der Weiterleitungsregel des Load Balancers.

  2. Erstellen Sie die Autorisierungsrichtlinie und importieren Sie die YAML-Datei.

    Mit dem folgenden Beispielbefehl importieren Sie die zuvor erstellte Richtliniendatei und erstellen die Autorisierungsrichtlinien:

    gcloud beta network-security authz-policies import my-authz-policy-allow \
    --source=authz-policy-allow.yaml \
    --location=global

Regional

Wenn Sie einen regionalen externen oder einen regionalen internen Application Load Balancer verwenden, gehen Sie so vor, um die Autorisierungsrichtlinie zu erstellen und zu importieren:

  1. Erstellen Sie die Autorisierungsrichtliniendatei, um bestimmte Anfragen zuzulassen.

    Im folgenden Beispiel wird eine authz-policy-allow.yaml-Datei für die Weiterleitungsregel LB_FORWARDING_RULE in einer bestimmten Google Cloud Region erstellt. Die Richtlinie erlaubt nur Clients von *.example.com, auf den URL-Pfad /api/payments zuzugreifen.

    $ cat >authz-policy-allow.yaml <<EOF
name: my-authz-policy-allow
target:
  loadBalancingScheme: LB_SCHEME
  resources:
  - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/LOCATION/forwardingRules/LB_FORWARDING_RULE"
httpRules:
- from:
  sources:
  - principals:
    - suffix: ".example.com"
  to:
    operations:
    - paths:
      - exact: "/api/payments"
action: ALLOW
EOF

    Ersetzen Sie Folgendes:

    • LB_SCHEME: Ihr Load Balancing-Schema. Wenn Sie regionale externe Application Load Balancer verwenden, legen Sie das Schema auf EXTERNAL_MANAGED fest. Wenn Sie regionale interne Application Load Balancer verwenden, legen Sie das Schema auf INTERNAL_MANAGED fest.
    • PROJECT_ID ist die ID Ihres Google Cloud-Projekts.
    • LOCATION: Ihrer Google Cloud Region.
    • LB_FORWARDING_RULE: der Name der Weiterleitungsregel des Load Balancers.

  2. Erstellen Sie die Autorisierungsrichtlinie und importieren Sie die YAML-Datei.

    Mit dem folgenden Beispielbefehl importieren Sie die zuvor erstellte Richtliniendatei und erstellen die Autorisierungsrichtlinien in der Region LOCATION:

    gcloud beta network-security authz-policies import my-authz-policy-allow \
    --source=authz-policy-allow.yaml \
    --location=LOCATION

Autorisierungsrichtlinie basierend auf Dienstkonten oder Tags

Autorisierungsrichtlinien, die auf Dienstkonten oder Tags basieren, können nur auf interne Application Load Balancer angewendet werden. Der gesamte Traffic, der von einer Client-VM stammt, die mit einem bestimmten Dienstkonto oder Tag verknüpft ist, kann entweder zugelassen, abgelehnt oder an einen externen Dienst delegiert werden.

Wenn Sie Dienstkonten oder Tags erstellen und an Google Cloud VMs anhängen möchten, lesen Sie den Abschnitt Dienstkonten oder Tags erstellen und an Google Cloud VMs anhängen in diesem Dokument.

Dienstkonto

  1. Erstellen Sie die Autorisierungsrichtliniendatei, um bestimmte Anfragen abzulehnen.

    Im folgenden Beispiel wird eine authz-policy-deny.yaml-Datei für die Weiterleitungsregel LB_FORWARDING_RULE eines regionalen internen Application Load Balancers erstellt. Die Richtlinie ist so konfiguriert, dass Anfragen von allen Client-VMs mit dem Dienstkonto my-sa-123@PROJECT_ID.iam.gserviceaccount.com den Pfad /api/payments nicht erreichen können.

    $ cat >authz-policy-deny.yaml <<EOF
name: my-authz-policy-deny
target:
  loadBalancingScheme: LB_SCHEME
  resources:
  - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/LOCATION/forwardingRules/LB_FORWARDING_RULE"
httpRules:
- from:
    sources:
    - resources:
       - iamServiceAccount:
           exact: "my-sa-123@PROJECT_ID.iam.gserviceaccount.com"
  to:
    operations:
    - paths:
      - prefix: "/api/payments"
action: DENY
EOF

    Ersetzen Sie Folgendes:

    • LB_SCHEME: Ihr Load Balancing-Schema. Legen Sie für einen regionalen internen Application Load Balancer das Schema auf INTERNAL_MANAGED fest.
    • PROJECT_ID ist die ID Ihres Google Cloud-Projekts.
    • LOCATION: Ihrer Google Cloud Region.
    • LB_FORWARDING_RULE: der Name der Weiterleitungsregel des Load Balancers.

  2. Erstellen Sie die Autorisierungsrichtlinie und importieren Sie die YAML-Datei.

    Mit dem folgenden Beispielbefehl importieren Sie die zuvor erstellte Richtliniendatei und erstellen die Autorisierungsrichtlinie in der angegebenen Region Google Cloud .

    gcloud beta network-security authz-policies import my-authz-policy-deny \
    --source=authz-policy-deny.yaml \
    --location=LOCATION

    Ersetzen Sie Folgendes:

    • LOCATION: Ihrer Google Cloud Region.

Tag

  1. Erstellen Sie die Autorisierungsrichtliniendatei, um bestimmte Anfragen zuzulassen.

    Im folgenden Beispiel wird eine authz-policy-allow.yaml-Datei für die Weiterleitungsregel LB_FORWARDING_RULE eines regionalen internen Application Load Balancers erstellt. Die Richtlinie erlaubt nur Anfragen, die von einer VM mit dem Ressourcen-Tag TAG_VALUE stammen, auf den URL-Pfad /api/payments zuzugreifen.

    $ cat >authz-policy-allow.yaml <<EOF
name: my-authz-policy-allow
target:
  loadBalancingScheme: LB_SCHEME
  resources:
  - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/LOCATION/forwardingRules/LB_FORWARDING_RULE"
httpRules:
- from:
  sources:
    resources:
    - tagValueIdSet:
      - ids: "TAG_VALUE"
  to:
    operations:
    - paths:
      - exact: "/api/payments"
action: ALLOW
EOF

    Ersetzen Sie Folgendes:

    • LB_SCHEME: Ihr Load Balancing-Schema. Legen Sie für einen regionalen internen Application Load Balancer das Schema auf INTERNAL_MANAGED fest.
    • PROJECT_ID ist die ID Ihres Google Cloud-Projekts.
    • LOCATION: Ihrer Google Cloud Region.
    • LB_FORWARDING_RULE: der Name der Weiterleitungsregel des Load Balancers.

  2. Erstellen Sie die Autorisierungsrichtlinie und importieren Sie die YAML-Datei.

    Mit dem folgenden Beispielbefehl importieren Sie die zuvor erstellte Richtliniendatei und erstellen die Autorisierungsrichtlinien in der angegebenen RegionGoogle Cloud :

    gcloud beta network-security authz-policies import my-authz-policy-allow \
    --source=authz-policy-allow.yaml \
    --location=LOCATION

    Ersetzen Sie Folgendes:

    • LOCATION: Ihrer Google Cloud Region.

Autorisierungsrichtlinie zum Delegieren an eine Diensterweiterung

Richten Sie zuerst eine externe Autorisierungs-Engine ein. Weitere Informationen zu Diensterweiterungen finden Sie unter Übersicht über Cloud Load Balancing-Hinweise.

Global und regionsübergreifend

Wenn Sie einen globalen externen oder einen regionenübergreifenden internen Application Load Balancer verwenden, gehen Sie so vor, um die Autorisierungsrichtlinie zu erstellen und zu importieren:

  1. Erstellen Sie die Autorisierungsrichtliniendatei, um bestimmte Anfragen an einen externen Dienst zu delegieren.

    Im folgenden Beispiel wird eine authz-policy-custom.yaml-Datei für die Weiterleitungsregel LB_FORWARDING_RULE am Standort global erstellt. Die Richtlinie ruft die AUTHZ_EXTENSION-Erweiterung für den gesamten Traffic zum /api/payments-URL-Pfad auf, wenn die Anfrage einen nicht leeren Authorization-Header enthält.

    $ cat >authz-policy-custom.yaml <<EOF
name: my-authz-policy-custom
target:
  loadBalancingScheme: LB_SCHEME
  resources:
  - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules/LB_FORWARDING_RULE"
httpRules:
- to:
    operations:
    - paths:
      - exact: "/api/payments"
  when: 'request.headers["Authorization"] != ""'
action: CUSTOM
customProvider:
  authzExtension:
    resources:
    - "https://networkservices.googleapis.com/v1/projects/PROJECT_ID/locations/global/authzExtensions/AUTHZ_EXTENSION"
EOF

    Ersetzen Sie Folgendes:

    • LB_SCHEME: Ihr Load Balancing-Schema. Legen Sie für globale externe Application Load Balancer das Schema auf EXTERNAL_MANAGED fest. Legen Sie für regionenübergreifende interne Application Load Balancer das Schema auf INTERNAL_MANAGED fest.
    • PROJECT_ID: die ID Ihres Google Cloud-Projekts.
    • LB_FORWARDING_RULE: der Name der Weiterleitungsregel des Load Balancers.
    • AUTHZ_EXTENSION: der Name der Autorisierungserweiterung.

  2. Erstellen Sie die Autorisierungsrichtlinie und importieren Sie die YAML-Datei.

    Mit dem folgenden Beispielbefehl importieren Sie die zuvor erstellte Richtliniendatei und erstellen die Autorisierungsrichtlinien:

    gcloud beta network-security authz-policies import my-authz-policy-custom \
    --source=authz-policy-custom.yaml \
    --location=global

Regional

Wenn Sie einen regionalen externen oder einen regionalen internen Application Load Balancer verwenden, gehen Sie so vor, um die Autorisierungsrichtlinie zu erstellen und zu importieren:

  1. Erstellen Sie die Autorisierungsrichtliniendatei, um bestimmte Anfragen an einen externen Dienst zu delegieren.

    Im folgenden Beispiel wird eine authz-policy-custom.yaml-Datei für die Weiterleitungsregel LB_FORWARDING_RULE in der Region Google Cloud eines regionalen internen Application Load Balancers erstellt. Die Richtlinie ruft die AUTHZ_EXTENSION-Erweiterung für den gesamten Traffic zum /api/payments-URL-Pfad auf, wenn die Anfrage einen nicht leeren Authorization-Header enthält.

    $ cat >authz-policy-custom.yaml <<EOF
name: my-authz-policy-custom
target:
  loadBalancingScheme: LB_SCHEME
  resources:
  - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/LOCATION/forwardingRules/LB_FORWARDING_RULE"
httpRules:
- to:
    operations:
    - paths:
      - exact: "/api/payments"
  when: 'request.headers["Authorization"] != ""'
action: CUSTOM
customProvider:
  authzExtension:
    resources:
    - "https://networkservices.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/authzExtensions/AUTHZ_EXTENSION"
EOF

    Ersetzen Sie Folgendes:

    • LB_SCHEME: Ihr Load Balancing-Schema. Legen Sie für regionale externe Application Load Balancer das Schema auf EXTERNAL_MANAGED fest. Legen Sie für regionale interne Application Load Balancer das Schema auf INTERNAL_MANAGED fest.
    • PROJECT_ID ist die ID Ihres Google Cloud-Projekts.
    • LOCATION: Ihrer Google Cloud Region.
    • LB_FORWARDING_RULE: der Name der Weiterleitungsregel des Load Balancers.
    • AUTHZ_EXTENSION: der Name der Autorisierungserweiterung.

  2. Erstellen Sie die Autorisierungsrichtlinie und importieren Sie die YAML-Datei.

    Mit dem folgenden Beispielbefehl importieren Sie die zuvor erstellte Richtliniendatei und erstellen die Autorisierungsrichtlinien in der Region LOCATION:

    gcloud beta network-security authz-policies import my-authz-policy-custom \
    --source=authz-policy-custom.yaml \
    --location=LOCATION

Autorisierungsrichtlinien testen

Senden Sie zum Testen der Autorisierungsrichtlinien etwas Traffic an den Load Balancer. Weitere Informationen finden Sie auf den folgenden Seiten:

  • Wenn Sie einen regionalen externen Application Load Balancer verwenden, lesen Sie den Hilfeartikel Load Balancer testen.

  • Wenn Sie einen regionalen internen Application Load Balancer verwenden, lesen Sie den Hilfeartikel Load Balancer testen.

  • Wenn Sie einen regionenübergreifenden internen Application Load Balancer verwenden, lesen Sie den Hilfeartikel Load Balancer testen.

Logs zu Autorisierungsrichtlinien in Cloud Logging

In den folgenden Abschnitten erfahren Sie, wie die Autorisierungsrichtlinien protokolliert werden, wenn eine Anfrage zugelassen oder abgelehnt wird.

Anfrage entspricht weder der ALLOW- noch der DENY-Richtlinie

Wenn eine Anfrage weder der ALLOW- noch der DENY-Richtlinie entspricht, wird sie gemäß der DENY-Richtlinie zugelassen und als allowed_as_no_deny_policies_matched_request protokolliert. Im Gegensatz dazu wird die Anfrage gemäß der ALLOW-Richtlinie abgelehnt und als denied_as_no_allow_policies_matched_request protokolliert. Da eine der Richtlinien die Anfrage ablehnt, wird sie abgelehnt.

  • Wenn Sie einen globalen externen Application Load Balancer verwenden, ist statusDetails im Log auf denied_by_authz_policy festgelegt. Sehen Sie sich folgendes Beispiel an:

      {
    httpRequest: {8}
    insertId: "example-id"
    jsonPayload: {
      @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
      authzPolicyInfo: {
        policies: [
          0: {
            details: "allowed_as_no_deny_policies_matched_request"
            result: "ALLOWED"
          }
          1: {
            details: "denied_as_no_allow_policies_matched_request"
            result: "DENIED"
          }
        ]
        result: "DENIED"
      }
      backendTargetProjectNumber: "projects/12345567"
      remoteIp: "00.100.11.104"
      statusDetails: "denied_by_authz_policy"
    }
    logName: "projects/example-project/logs/requests"
    receiveTimestamp: "2024-08-28T15:33:56.046651035Z"
    resource: {2}
    severity: "WARNING"
    spanId: "3e1a09a8e5e3e14d"
    timestamp: "2024-08-28T15:33:55.355042Z"
    trace: "projects/example-project/traces/8c8b3dbf9a19c85954d0fa2d958ca509"
  }

  • Wenn Sie einen regionalen internen, einen regionalen externen oder einen regionenübergreifenden internen Application Load Balancer verwenden, ist proxyStatus im Log auf error=\"http_request_error\"; details=\"denied_by_authz_policy\" festgelegt. Sehen Sie sich folgendes Beispiel an:

      {
    httpRequest: {8}
    insertId: "example-id"
    jsonPayload: {
      @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
      authzPolicyInfo: {
        policies: [
          0: {
            details: "allowed_as_no_deny_policies_matched_request"
            result: "ALLOWED"
          }
          1: {
            details: "denied_as_no_allow_policies_matched_request"
            result: "DENIED"
          }
        ]
        result: "DENIED"
      }
      backendTargetProjectNumber: "projects/12345567"
      remoteIp: "00.100.11.104"
      proxyStatus: "error=\"http_request_error\"; details=\"denied_by_authz_policy\""
    }
    logName: "projects/example-project/logs/requests"
    receiveTimestamp: "2024-08-28T15:33:56.046651035Z"
    resource: {2}
    severity: "WARNING"
    spanId: "3e1a09a8e5e3e14d"
    timestamp: "2024-08-28T15:33:55.355042Z"
    trace: "projects/example-project/traces/8c8b3dbf9a19c85954d0fa2d958ca509"
  }

Anfrage entspricht der DENY-Richtlinie

Wenn eine Anfrage mit der DENY-Richtlinie übereinstimmt, wird sie abgelehnt und die Richtlinie, die die Anfrage abgelehnt hat, wird protokolliert.

  • Wenn Sie einen globalen externen Application Load Balancer verwenden, ist statusDetails im Log auf denied_by_authz_policy festgelegt und der Name der Richtlinie, die die Anfrage abgelehnt hat, wird in policies protokolliert. Sehen Sie sich folgendes Beispiel an:

      {
    httpRequest: {8}
    insertId: "example-id"
    jsonPayload: {
      @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
      authzPolicyInfo: {
        policies: [
          0: {
            details: "name: "projects/12345567/locations/global/authzPolicies/deny-authz-policy-test""
            result: "DENIED"
          }
        ]
        result: "DENIED"
      }
      backendTargetProjectNumber: "projects/12345567"
      cacheDecision: [2]
      remoteIp: "00.100.11.104"
      statusDetails: "denied_by_authz_policy"
    }
    logName: "projects/example-project/logs/requests"
    receiveTimestamp: "2024-08-28T15:33:56.046651035Z"
    resource: {2}
    severity: "WARNING"
    spanId: "3e1a09a8e5e3e14d"
    timestamp: "2024-08-28T15:33:55.355042Z"
    trace: "projects/example-project/traces/8c8b3dbf9a19c85954d0fa2d958ca509"
  }

  • Wenn Sie einen regionalen internen Application Load Balancer, einen regionalen externen Application Load Balancer oder einen regionenübergreifenden internen Application Load Balancer verwenden, ist proxyStatus auf error=\"http_request_error\"; details=\"denied_by_authz_policy\" festgelegt und der Name der Richtlinie wird in policies protokolliert. Sehen Sie sich folgendes Beispiel an:

      {
    httpRequest: {8}
    insertId: "example-id"
    jsonPayload: {
      @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
      authzPolicyInfo: {
        policies: [
          0: {
            details: "name: "projects/12345567/locations/$REGION/authzPolicies/deny-authz-policy-test""
            result: "DENIED"
          }
        ]
        result: "DENIED"
      }
      backendTargetProjectNumber: "projects/12345567"
      remoteIp: "00.100.11.104"
      proxyStatus: "error=\"http_request_error\"; details=\"denied_by_authz_policy\""
    }
    logName: "projects/example-project/logs/requests"
    receiveTimestamp: "2024-08-28T15:33:56.046651035Z"
    resource: {2}
    severity: "WARNING"
    spanId: "3e1a09a8e5e3e14d"
    timestamp: "2024-08-28T15:33:55.355042Z"
    trace: "projects/example-project/traces/8c8b3dbf9a19c85954d0fa2d958ca509"
  }

Anfrage entspricht nicht der DENY-Richtlinie, aber der ALLOW-Richtlinie

Wenn eine Anfrage nicht mit der DENY-Richtlinie, aber mit der ALLOW-Richtlinie übereinstimmt, ist sie zulässig. Im Log wird diese Aktion als allowed_as_no_deny_policies_matched_request für die Richtlinie DENY protokolliert. Die Richtlinie, die die Anfrage zugelassen hat, wird ebenfalls protokolliert.

  • Wenn Sie einen globalen externen Application Load Balancer verwenden, ist im Protokoll kein statusDetails enthalten. Die Richtlinie, die die Anfrage zugelassen hat, wird ebenfalls in policies protokolliert. Sehen Sie sich folgendes Beispiel an:

      {
    httpRequest: {8}
    insertId: "example-id"
    jsonPayload: {
      @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
      authzPolicyInfo: {
        policies: [
          0: {
            details: "allowed_as_no_deny_policies_matched_request"
            result: "ALLOWED"
          }
          1: {
            details: "name: "projects/12345567/locations/global/authzPolicies/allow-authz-policy-test""
            result: "ALLOWED"
          }
        ]
        result: "ALLOWED"
      }
      backendTargetProjectNumber: "projects/12345567"
      cacheDecision: [2]
      remoteIp: "00.100.11.104"
    }
    logName: "projects/example-project/logs/requests"
    receiveTimestamp: "2024-08-28T15:33:56.046651035Z"
    resource: {2}
    severity: "WARNING"
    spanId: "3e1a09a8e5e3e14d"
    timestamp: "2024-08-28T15:33:55.355042Z"
    trace: "projects/example-project/traces/8c8b3dbf9a19c85954d0fa2d958ca509"
  }

  • Wenn Sie einen regionalen internen Application Load Balancer, einen regionalen externen Application Load Balancer oder einen regionenübergreifenden internen Application Load Balancer verwenden, ist im Protokoll kein Feld proxyStatus vorhanden. Die Richtlinie, die die Anfrage zugelassen hat, wird ebenfalls in policies protokolliert. Sehen Sie sich folgendes Beispiel an:

      {
    httpRequest: {8}
    insertId: "example-id"
    jsonPayload: {
      @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
      authzPolicyInfo: {
        policies: [
          0: {
            details: "allowed_as_no_deny_policies_matched_request"
            result: "ALLOWED"
          }
          1: {
            details: "name: "projects/12345567/locations/$REGION/authzPolicies/allow-authz-policy-test""
            result: "ALLOWED"
          }
        ]
        result: "ALLOWED"
      }
      backendTargetProjectNumber: "projects/12345567"
      cacheDecision: [2]
      remoteIp: "00.100.11.104"
    }
    logName: "projects/example-project/logs/requests"
    receiveTimestamp: "2024-08-28T15:33:56.046651035Z"
    resource: {2}
    severity: "WARNING"
    spanId: "3e1a09a8e5e3e14d"
    timestamp: "2024-08-28T15:33:55.355042Z"
    trace: "projects/example-project/traces/8c8b3dbf9a19c85954d0fa2d958ca509"
  }

Nächste Schritte