Autorisierungsrichtlinien für Application Load Balancer einrichten

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:

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

Bei internen Application Load Balancern können Sie Autorisierungsrichtlinien basierend auf Dienstkonten oder Tags anwenden, die an verschiedene Google Cloud-Ressourcen angehängt sind.

Das Beispiel in diesem Dokument enthält eine Anleitung zum Erstellen einer Autorisierungsrichtlinie basierend auf Dienstkonten oder Tags, die an Google Cloud VM-Instanzen angehängt sind. Jede Anfrage, die 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. Ein Beispiel für eine solche Autorisierungsrichtlinie, in der Dienstkonten und Tags verwendet werden, um die Zugriffssteuerung zu erzwingen, finden Sie in diesem Dokument im Abschnitt Autorisierungsrichtlinie basierend auf Dienstkonten oder Tags.

Das Anwenden von Autorisierungsrichtlinien basierend auf Dienstkonten oder Tags 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 an die Instanzgruppenvorlage binden, müssen Sie einen Tag-Schlüssel und einen Tag-Wert erstellen. Wenn Sie ein Tag erstellen, weisen Sie ihm den Zweck GCE_FIREWALL Google Cloud zu.Für Netzwerkfunktionen wie Secure Web-Proxy und Autorisierungsrichtlinien ist der Zweck GCE_FIREWALL 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 den 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 Netzwerkfirewall 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 ein numerischer Wert sein.

  9. Geben Sie im Feld Beschreibung des Tag-Werts 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 Wert des Tags an die VMs oder die Backends der Vorlage anhängen.

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

  1. Definieren Sie das Präfix für den vollständigen Namen für Ihr Projekt und Ihre Zone:

    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. Instanzgruppenvorlagen-ID abrufen:

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

    Ersetzen Sie Folgendes:

    • TEMPLATE_NAME: Name Ihrer 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 Ihres 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

In diesem Abschnitt finden Sie ein Beispiel für eine Autorisierungsrichtlinie, mit der Anfragen basierend auf Clientzertifikathauptkonten abgelehnt werden.

Global und regionsübergreifend

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

  1. Erstellen Sie eine YAML-Datei für die Autorisierungsrichtlinie, 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 verweigert den Zugriff auf den /api/payments-URL-Pfad für Clients, die www.example.com in den SANs des DNS-Namens ihres Clientzertifikats haben.

    $ 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:
      - principalSelector: CLIENT_CERT_DNS_NAME_SAN
        exact: "www.example.com"
  to:
    operations:
    - paths:
      - prefix: "/api/payments"
action: DENY
EOF

    Ersetzen Sie Folgendes:

    • LB_SCHEME: Ihr Load-Balancing-Schema. Legen Sie für den globalen externen 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 eine Autorisierungsrichtlinie und importieren Sie die YAML-Datei.

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

    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 internen Application Load Balancer verwenden, gehen Sie so vor, um eine Autorisierungsrichtlinie zu erstellen und zu importieren:

  1. Erstellen Sie eine YAML-Datei für die Autorisierungsrichtlinie, um bestimmte Anfragen abzulehnen.

    Im folgenden Beispiel wird eine authz-policy-deny.yaml-Datei für die Weiterleitungsregel LB_FORWARDING_RULE in einerGoogle Cloud -Region erstellt. Die Richtlinie verweigert den Zugriff auf den /api/payments-URL-Pfad für Clients, die www.example.com in ihren DNS-Namen-SANs des Clientzertifikats haben.

    $ 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:
      - principalSelector: CLIENT_CERT_DNS_NAME_SAN
        exact: "www.example.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 eine Autorisierungsrichtlinie und importieren Sie die YAML-Datei.

    Mit dem folgenden Beispielbefehl importieren Sie die zuvor erstellte Richtliniendatei und erstellen eine Autorisierungsrichtlinie 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

In diesem Abschnitt finden Sie ein Beispiel für eine Autorisierungsrichtlinie, die Anfragen aus bestimmten IP-Adressbereichen zulässt.

Global und regionsübergreifend

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

  1. Erstellen Sie eine YAML-Datei für die Autorisierungsrichtlinie, 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 Clients mit IP-Adressen im Bereich 10.0.0.1/24 den Zugriff auf den URL-Pfad /api/payments.

    $ 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:
    - ipBlocks:
      - prefix: "10.0.0.1"
        length: "24"
  to:
    operations:
    - paths:
      - exact: "/api/payments"
action: ALLOW
EOF

    Ersetzen Sie Folgendes:

    • LB_SCHEME: Ihr Load-Balancing-Schema. Legen Sie für den globalen externen 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 eine Autorisierungsrichtlinie und importieren Sie die YAML-Datei.

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

    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 internen Application Load Balancer verwenden, gehen Sie so vor, um eine Autorisierungsrichtlinie zu erstellen und zu importieren:

  1. Erstellen Sie eine YAML-Datei für die Autorisierungsrichtlinie, 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 Clients mit IP-Adressen im Bereich 10.0.0.1/24 den Zugriff auf den URL-Pfad /api/payments.

    $ 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:
    - ipBlocks:
      - prefix: "10.0.0.1"
        length: "24"
  to:
    operations:
    - paths:
      - exact: "/api/payments"
action: ALLOW
EOF

    Ersetzen Sie Folgendes:

    • LB_SCHEME: Ihr Load-Balancing-Schema. Wenn Sie einen regionalen externen Application Load Balancer verwenden, legen Sie das Schema auf EXTERNAL_MANAGED fest. Wenn Sie einen regionalen internen 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 eine Autorisierungsrichtlinie und importieren Sie die YAML-Datei.

    Mit dem folgenden Beispielbefehl importieren Sie die zuvor erstellte Richtliniendatei und erstellen eine Autorisierungsrichtlinie 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

Sie können Autorisierungsrichtlinien basierend auf Dienstkonten oder Tags nur auf interne Application Load Balancer anwenden. 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 für Google Cloud VMs erstellen und anhängen möchten, lesen Sie den Abschnitt Dienstkonten oder Tags für Google Cloud VMs erstellen und anhängen in diesem Dokument.

Dienstkonto

  1. Erstellen Sie eine YAML-Datei für die Autorisierungsrichtlinie, 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 Balancer erstellt. Die Richtlinie ist so konfiguriert, dass Anfragen von Client-VMs mit dem Dienstkonto my-sa-123@PROJECT_ID.iam.gserviceaccount.com, die den Pfad /api/payments erreichen möchten, abgelehnt werden.

    $ 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: die ID Ihres Google Cloud Projekts.
    • LOCATION: Ihre Google Cloud Region.
    • LB_FORWARDING_RULE: der Name der Weiterleitungsregel des Load-Balancers.

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

    Mit dem folgenden Beispielbefehl importieren Sie die zuvor erstellte Richtliniendatei und erstellen eine 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: Ihre Google Cloud Region.

Tag

  1. Erstellen Sie eine YAML-Datei für die Autorisierungsrichtlinie, 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 Balancer erstellt. Die Richtlinie lässt nur Anfragen zu, die von einer VM mit dem Ressourcentag TAG_VALUE stammen und auf den URL-Pfad /api/payments zugreifen.

    $ 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: die ID Ihres Google Cloud Projekts.
    • LOCATION: Ihre Google Cloud Region.
    • LB_FORWARDING_RULE: der Name der Weiterleitungsregel des Load-Balancers.

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

    Mit dem folgenden Beispielbefehl importieren Sie die zuvor erstellte Richtliniendatei und erstellen eine Autorisierungsrichtlinie 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: Ihre Google Cloud Region.

Autorisierungsrichtlinie zum Delegieren an eine Diensterweiterung

Richten Sie eine externe Autorisierungs-Engine ein, bevor Sie beginnen. Weitere Informationen zu Diensterweiterungen finden Sie unter Cloud Load Balancing-Callouts.

Global und regionsübergreifend

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

  1. Erstellen Sie eine 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 Erweiterung AUTHZ_EXTENSION für den gesamten Traffic zum URL-Pfad /api/payments 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 den globalen externen 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 eine Autorisierungsrichtlinie und importieren Sie die YAML-Datei.

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

    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 internen Application Load Balancer verwenden, gehen Sie so vor, um eine Autorisierungsrichtlinie zu erstellen und zu importieren:

  1. Erstellen Sie eine YAML-Datei für die Autorisierungsrichtlinie, 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 Balancer erstellt. Die Richtlinie ruft die AUTHZ_EXTENSION-Erweiterung für alle Zugriffe auf den URL-Pfad /api/payments 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 eine Autorisierungsrichtlinie und importieren Sie die YAML-Datei.

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

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

Autorisierungsrichtlinie testen

Senden Sie zum Testen einer Autorisierungsrichtlinie 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 Abschnitt Load Balancer testen.

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

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

Logs für Autorisierungsrichtlinien in Cloud Logging

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

Die Anfrage entspricht weder der Richtlinie für ALLOW noch der Richtlinie für DENY

Wenn eine Anfrage weder der ALLOW- noch der DENY-Richtlinie entspricht, wird sie von der DENY-Richtlinie zugelassen und als allowed_as_no_deny_policies_matched_request protokolliert. Umgekehrt wird die Anfrage bei der ALLOW-Richtlinie abgelehnt und als denied_as_no_allow_policies_matched_request protokolliert. Da eine der Richtlinien die Anfrage ablehnt, wird die Anfrage abgelehnt.

  • Wenn Sie einen globalen externen Application Load Balancer verwenden, wird statusDetails im Log auf denied_by_authz_policy gesetzt. 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 Application Load Balancer, einen regionalen externen Application Load Balancer oder einen regionenübergreifenden internen Application Load Balancer verwenden, wird proxyStatus im Log auf error=\"http_request_error\"; details=\"denied_by_authz_policy\" gesetzt. 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 der DENY-Richtlinie entspricht, wird sie abgelehnt und die Richtlinie, die die Anfrage abgelehnt hat, wird protokolliert.

  • Wenn Sie einen globalen externen Application Load Balancer verwenden, wird statusDetails im Log auf denied_by_authz_policy gesetzt 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, wird proxyStatus auf error=\"http_request_error\"; details=\"denied_by_authz_policy\" gesetzt 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"
  }

Die Anfrage entspricht nicht der Richtlinie „DENY“, aber der Richtlinie „ALLOW“

Wenn eine Anfrage nicht der DENY-Richtlinie, aber der ALLOW-Richtlinie entspricht, 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 kein statusDetails im Log 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/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 Log kein proxyStatus-Feld 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