Autorisierungsrichtlinien für Application Load Balancer einrichten

Bei Application Load Balancern werden Autorisierungsrichtlinien nach der Auswertung von Routenerweiterungen, Netzwerksicherheitsrichtlinien (von Google Cloud Armor ausgewertet), CORS-Richtlinien (Cross-Origin Resource Sharing) und Identity-Aware Proxy (IAP) aufgerufen, aber vor der Ausführung von Traffic-Management-Aktionen.

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

Hinweise

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:

Sichere Tags oder Dienstkonten erstellen und konfigurieren

Bei internen Application Load Balancern können Sie optional Autorisierungsrichtlinien basierend auf den sicheren Tags und Dienstkonten anwenden, die an die Client-VMs angehängt sind. Wenn Sie tagbasierte Autorisierungsrichtlinien anwenden möchten, verwenden Sie Resource Manager, um Tags zu erstellen.

Wenn Sie externe Application Load Balancer verwenden, müssen Sie keine sicheren Tags erstellen und konfigurieren.

Weitere Informationen finden Sie unter Tags für Firewalls verwenden und Dienstkonten.

Dienstkonten an Client-VMs anhängen

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

Sichere Tag-Schlüssel und -Werte erstellen

Bevor Sie ein sicheres Tag mit der Instanzgruppenvorlage verknüpfen, müssen Sie die Tag-Schlüssel und ‑Werte erstellen. Wenn Sie ein Tag erstellen, weisen Sie ihm einen GCE_FIREWALL-Zweck zu. Für Google Cloud-Netzwerkfunktionen wie Secure Web Proxy und Autorisierungsrichtlinien ist der Zweck GCE_FIREWALL erforderlich, um das Tag anzuwenden.

Zum Erstellen sicherer 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 sicheren 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 sicheren 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 sicheren 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.

Sicheres Tag an die Instanzgruppenvorlage binden

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

Zum Binden sicherer 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: Ihre 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: Ihre 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 zuzulassen.

    Im folgenden Beispiel wird eine authz-policy-deny.yaml-Datei für die Weiterleitungsregel LB_FORWARDING_RULE in einer Google Cloud-Region erstellt. Die Richtlinie verbietet Clients mit Identitäten, die mit *.hello.com übereinstimmen, den Zugriff auf den URL-Pfad /api/payments. Außerdem wird mit der Richtlinie der Zugriff auf die URL /api/payments für alle Client-VMs mit dem Dienstkonto my-sa-123@PROJECT_ID.iam.gserviceaccount.com verweigert.

    $ 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"
- 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 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: die ID Ihres Google Cloud-Projekts.
    • LOCATION: Ihre 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 Google Cloud-Region eines regionalen internen Application Load Balancers erstellt. Die Richtlinie erlaubt nur Clients von *.example.com, auf den URL-Pfad /api/payments zuzugreifen, wenn die Anfrage von einer VM mit dem Ressourcen-Tag TAG_VALUE stammt.

    $ 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"
    resources:
    - tagValueIdSet:
      - ids: "TAG_VALUE"
  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: die ID Ihres Google Cloud-Projekts.
    • LOCATION: Ihre 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 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 einer Google Cloud-Region 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: die ID Ihres Google Cloud-Projekts.
    • LOCATION: Ihre 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

Weitere Informationen dazu, wie die Autorisierungsrichtlinien protokolliert werden, wenn eine Anfrage zugelassen oder abgelehnt wird, finden Sie unter den folgenden Links:

  • Wenn eine Anfrage weder der ALLOW- noch der DENY-Richtlinie entspricht, erlaubt die DENY-Richtlinie die Anfrage und protokolliert sie als allowed_as_no_deny_policies_matched_request. Umgekehrt lehnt die ALLOW-Richtlinie die Anfrage ab und protokolliert sie als denied_as_no_allow_policies_matched_request. 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"
      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"
  }

    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"
  }

  • 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"
  }

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

    Wenn Sie einen globalen externen Application Load Balancer verwenden, ist im Log 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