Cette page a été traduite par l'API Cloud Translation.

Configurer des règles d'autorisation pour les équilibreurs de charge d'application

Dans les équilibreurs de charge d'application, les stratégies d'autorisation sont appelées après l'évaluation des extensions de route, des stratégies de sécurité réseau (évaluées par Google Cloud Armor), des règles de Cross-Origin Resource Sharing (CORS) et d'Identity-Aware Proxy (IAP), mais avant l'exécution des actions de gestion du trafic.

Cette page vous explique comment configurer des règles d'autorisation pour les équilibreurs de charge d'application.

Avant de commencer

Familiarisez-vous avec la présentation des règles d'autorisation.
Activez les API suivantes :
- API de sécurité réseau
- API de services réseau

Configurer l'équilibreur de charge

Si vous n'avez pas créé d'équilibreur de charge, consultez les pages suivantes pour configurer l'équilibreur de charge d'application de votre choix:

Pour créer un équilibreur de charge d'application externe global, consultez Configurer un équilibreur de charge d'application externe global avec des backends de groupe d'instances de VM.

Pour créer un équilibreur de charge d'application externe régional, consultez Configurer un équilibreur de charge d'application externe régional avec des backends de groupes d'instances de VM.
Pour créer un équilibreur de charge d'application interne régional, consultez Configurer un équilibreur de charge d'application interne régional avec des backends de groupes d'instances de VM.

Pour créer un équilibreur de charge d'application interne interrégional, consultez Configurer un équilibreur de charge d'application interne interrégional avec des backends de groupes d'instances de VM.

Créer et configurer des tags ou des comptes de service sécurisés

Avec les équilibreurs de charge d'application internes, vous pouvez éventuellement appliquer des stratégies d'autorisation en fonction des tags sécurisés et des comptes de service associés aux VM clientes. Si vous prévoyez d'appliquer des stratégies d'autorisation basées sur des balises, utilisez Resource Manager pour créer des balises.

Si vous utilisez des équilibreurs de charge d'application externes, vous n'avez pas besoin de créer ni de configurer de balises sécurisées.

Pour en savoir plus, consultez les pages Utiliser des tags pour les pare-feu et Comptes de service.

Associer des comptes de service aux VM clientes

Pour obtenir des informations détaillées sur le rattachement d'un compte de service à une instance de VM, consultez les documents suivants:

Pour configurer un compte de service lors de la création de la VM, consultez la page Créer une VM qui utilise un compte de service géré par l'utilisateur.
Pour configurer un compte de service sur une VM existante, consultez la section Modifier le compte de service associé.

Créer les clés et les valeurs de tags sécurisées

Avant d'associer un tag sécurisé au modèle de groupe d'instances, vous devez créer les clés et les valeurs des tags. Lorsque vous créez une balise, attribuez-lui un objectif GCE_FIREWALL. Les fonctionnalités de mise en réseau Google Cloud, y compris le proxy Web sécurisé et les règles d'autorisation, nécessitent l'objectif GCE_FIREWALL pour appliquer la balise.

Pour créer des balises sécurisées, vous devez disposer du rôle Administrateur de tags (roles/resourcemanager.tagAdmin).

Console

Dans la console Google Cloud, accédez à la page Tags.

Accéder à "Tags"
Cliquez sur Créer.
Dans le champ Description de la clé de tag, saisissez une description.
Cochez la case À utiliser avec le pare-feu du réseau.
Dans la liste Project (Projet), sélectionnez le projet Google Cloud dans lequel vous souhaitez créer la balise.
Dans le champ Réseau, sélectionnez LB_NETWORK.
Cliquez sur Ajouter une valeur.
Dans le champ Valeur de la balise, saisissez TAG_VALUE. La valeur doit être numérique.
Dans le champ Description de la valeur de tag, saisissez une description.
Lorsque vous avez terminé, cliquez sur Créer une clé de balise.

gcloud

Créez la clé de tag sécurisée.
```
gcloud resource-manager tags keys create TAG_KEY \
    --parent=organizations/ORG_ID \
    --purpose=GCE_FIREWALL \
    --purpose-data=network=LB_NETWORK
```
Remplacez les éléments suivants :
- TAG_KEY: nom de votre clé de tag sécurisée.
- ORG_ID : ID de votre organisation.
- LB_NETWORK : nom de votre réseau VPC.
Ajoutez la valeur de tag sécurisée à la clé de tag numérique.
```
gcloud resource-manager tags values create TAG_VALUE \
    --parent=ORG_ID/TAG_KEY
```
Remplacez TAG_VALUE par une valeur de balise numérique.

Lier la balise sécurisée au modèle de groupe d'instances

Les administrateurs de tags peuvent lier des tags sécurisés à des instances de VM individuelles ou au modèle de groupe d'instances, et associer la valeur du tag aux backends des VM ou du modèle.

Pour associer des tags sécurisés, vous devez disposer du rôle Utilisateur de tags (roles/resourcemanager.tagUser).

Définissez le préfixe du nom complet pour votre projet et votre zone :
```
FULL_NAME_PREFIX=//compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/instances/
```
Remplacez les éléments suivants :
- PROJECT_ID : par l'ID du projet.
- ZONE: zone dans laquelle se trouve le groupe d'instances géré.
Obtenez l'ID du modèle de groupe d'instances:
```
TEMPLATE_ID=$(gcloud compute instance-templates describe TEMPLATE_NAME --region=LOCATION --format='value(id)')
```
Remplacez les éléments suivants :
- TEMPLATE_NAME: nom de votre modèle de groupe d'instances.
- LOCATION: région Google Cloud
Concaténez les valeurs de FULL_NAME_PREFIX et de TEMPLATE_ID :
```
PARENT="$FULL_NAME_PREFIX$TEMPLATE_ID"
echo $PARENT
```
Créez les liaisons.
```
gcloud resource-manager tags bindings create \
    --location LOCATION \
    --tag-value ORG_ID/TAG_KEY/TAG_VALUE \
    --parent PARENT
```
Remplacez les éléments suivants :
- ORG_ID : ID de votre organisation.
- LOCATION: région Google Cloud
- TAG_KEY: nom de votre clé de tag sécurisée.
- TAG_VALUE: valeur numérique du tag.

Créer la règle d'autorisation

Pour créer une stratégie d'autorisation, vous devez créer un fichier YAML définissant la cible et les règles, puis importer le fichier à l'aide de la commande gcloud beta network-security authz-policies.

Cette section explique comment créer différents types de stratégies d'autorisation associées à la règle de transfert d'un équilibreur de charge.

Stratégie d'autorisation pour refuser les requêtes

Mondial et interrégional

Si vous utilisez un équilibreur de charge d'application externe global ou un équilibreur de charge d'application interne interrégional, procédez comme suit pour créer et importer la règle d'autorisation:

Créez le fichier de règles d'autorisation pour refuser certaines requêtes.

L'exemple suivant crée un fichier authz-policy-deny.yaml pour la règle de transfert LB_FORWARDING_RULE à l'emplacement global. La règle interdit aux clients de *.hello.com d'accéder au chemin d'URL /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
```
Remplacez les éléments suivants :
- LB_SCHEME: votre schéma d'équilibrage de charge. Pour l'équilibreur de charge d'application externe global, définissez le schéma sur EXTERNAL_MANAGED. Pour l'équilibreur de charge d'application interne interrégional, définissez le schéma sur INTERNAL_MANAGED.
- PROJECT_ID : ID de votre projet Google Cloud
- LB_FORWARDING_RULE: nom de la règle de transfert de l'équilibreur de charge.
Créez la stratégie d'autorisation et importez le fichier YAML.

L'exemple de commande suivant importe le fichier de règles créé précédemment et crée les règles d'autorisation:
```
gcloud beta network-security authz-policies import my-authz-policy-deny \
    --source=authz-policy-deny.yaml \
    --location=global
```

Régional

Si vous utilisez un équilibreur de charge d'application externe régional ou un équilibreur de charge d'application interne régional, procédez comme suit pour créer et importer la stratégie d'autorisation:

Créez le fichier de règles d'autorisation pour autoriser certaines requêtes.

L'exemple suivant crée un fichier authz-policy-deny.yaml pour la règle de transfert LB_FORWARDING_RULE dans une région Google Cloud. La règle interdit aux clients dont les identités correspondent à *.hello.com d'accéder au chemin d'URL /api/payments. La stratégie refuse également l'accès à l'URL /api/payments à toutes les VM clientes avec le compte de service my-sa-123@PROJECT_ID.iam.gserviceaccount.com.
```
$ 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
```
Remplacez les éléments suivants :
- LB_SCHEME: votre schéma d'équilibrage de charge. Pour l'équilibreur de charge d'application externe régional, définissez le schéma sur EXTERNAL_MANAGED. Pour l'équilibreur de charge d'application interne régional, définissez le schéma sur INTERNAL_MANAGED.
- PROJECT_ID : ID de votre projet Google Cloud
- LOCATION: région Google Cloud
- LB_FORWARDING_RULE: nom de la règle de transfert de l'équilibreur de charge.
Créez la stratégie d'autorisation et importez le fichier YAML.

L'exemple de commande suivant importe le fichier de stratégie créé précédemment et crée les règles d'autorisation dans la région LOCATION:
```
gcloud beta network-security authz-policies import my-authz-policy-deny \
    --source=authz-policy-deny.yaml \
    --location=LOCATION
```

Règle d'autorisation pour autoriser les requêtes

Mondial et interrégional

Créez le fichier de règles d'autorisation pour autoriser certaines requêtes.

L'exemple suivant crée un fichier authz-policy-allow.yaml pour la règle de transfert LB_FORWARDING_RULE à l'emplacement global. La règle n'autorise que les clients de *.example.com à accéder au chemin d'URL /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:
  - principals:
    - suffix: ".example.com"
  to:
    operations:
    - paths:
      - exact: "/api/payments"
action: ALLOW
EOF
```
Remplacez les éléments suivants :
- LB_SCHEME: votre schéma d'équilibrage de charge. Pour l'équilibreur de charge d'application externe global, définissez le schéma sur EXTERNAL_MANAGED. Pour l'équilibreur de charge d'application interne interrégional, définissez le schéma sur INTERNAL_MANAGED.
- PROJECT_ID : ID de votre projet Google Cloud
- LB_FORWARDING_RULE: nom de la règle de transfert de l'équilibreur de charge.
Créez la stratégie d'autorisation et importez le fichier YAML.

L'exemple de commande suivant importe le fichier de règles créé précédemment et crée les règles d'autorisation:
```
gcloud beta network-security authz-policies import my-authz-policy-allow \
    --source=authz-policy-allow.yaml \
    --location=global
```

Régional

Créez le fichier de règles d'autorisation pour autoriser certaines requêtes.

L'exemple suivant crée un fichier authz-policy-allow.yaml pour la règle de transfert LB_FORWARDING_RULE dans une région Google Cloud d'un équilibreur de charge d'application interne régional. La stratégie n'autorise que les clients de *.example.com à accéder au chemin d'URL /api/payments lorsque la requête provient d'une VM avec la balise de ressource TAG_VALUE.
```
$ 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
```
Remplacez les éléments suivants :
- LB_SCHEME: votre schéma d'équilibrage de charge. Si vous utilisez un équilibreur de charge d'application externe régional, définissez le schéma sur EXTERNAL_MANAGED. Si vous utilisez un équilibreur de charge d'application interne régional, définissez le schéma sur INTERNAL_MANAGED.
- PROJECT_ID : ID de votre projet Google Cloud
- LOCATION: région Google Cloud
- LB_FORWARDING_RULE: nom de la règle de transfert de l'équilibreur de charge.
Créez la stratégie d'autorisation et importez le fichier YAML.

L'exemple de commande suivant importe le fichier de stratégie créé précédemment et crée les règles d'autorisation dans la région LOCATION:
```
gcloud beta network-security authz-policies import my-authz-policy-allow \
    --source=authz-policy-allow.yaml \
    --location=LOCATION
```

Stratégie d'autorisation à déléguer à une extension de service

Avant de commencer, configurez un moteur d'autorisation externe. Pour en savoir plus sur les extensions de service, consultez la présentation des accroches Cloud Load Balancing.

Mondial et interrégional

Créez le fichier de règles d'autorisation pour déléguer certaines requêtes à un service externe.

L'exemple suivant crée un fichier authz-policy-custom.yaml pour la règle de transfert LB_FORWARDING_RULE dans l'emplacement global. La règle appelle l'extension AUTHZ_EXTENSION pour tout le trafic vers le chemin d'URL /api/payments lorsque la requête contient un en-tête Authorization non vide.
```
$ 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
```
Remplacez les éléments suivants :
- LB_SCHEME: votre schéma d'équilibrage de charge. Pour l'équilibreur de charge d'application externe global, définissez le schéma sur EXTERNAL_MANAGED. Pour l'équilibreur de charge d'application interne interrégional, définissez le schéma sur INTERNAL_MANAGED.
- PROJECT_ID : ID de votre projet Google Cloud
- LB_FORWARDING_RULE: nom de la règle de transfert de l'équilibreur de charge.
- AUTHZ_EXTENSION: nom de l'extension d'autorisation.
Créez la stratégie d'autorisation et importez le fichier YAML.

L'exemple de commande suivant importe le fichier de règles créé précédemment et crée les règles d'autorisation:
```
gcloud beta network-security authz-policies import my-authz-policy-custom \
    --source=authz-policy-custom.yaml \
    --location=global
```

Régional

Créez le fichier de règles d'autorisation pour déléguer certaines requêtes à un service externe.

L'exemple suivant crée un fichier authz-policy-custom.yaml pour la règle de transfert LB_FORWARDING_RULE dans une région Google Cloud d'un équilibreur de charge d'application interne régional. La règle appelle l'extension AUTHZ_EXTENSION pour tout le trafic vers le chemin d'URL /api/payments lorsque la requête contient un en-tête Authorization non vide.
```
$ 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
```
Remplacez les éléments suivants :
- LB_SCHEME: votre schéma d'équilibrage de charge. Pour l'équilibreur de charge d'application externe régional, définissez le schéma sur EXTERNAL_MANAGED. Pour l'équilibreur de charge d'application interne régional, définissez le schéma sur INTERNAL_MANAGED.
- PROJECT_ID : ID de votre projet Google Cloud
- LOCATION: région Google Cloud
- LB_FORWARDING_RULE: nom de la règle de transfert de l'équilibreur de charge.
- AUTHZ_EXTENSION: nom de l'extension d'autorisation.
Créez la stratégie d'autorisation et importez le fichier YAML.

L'exemple de commande suivant importe le fichier de stratégie créé précédemment et crée les règles d'autorisation dans la région LOCATION:
```
gcloud beta network-security authz-policies import my-authz-policy-custom \
    --source=authz-policy-custom.yaml \
    --location=LOCATION
```

Tester les règles d'autorisation

Pour tester les règles d'autorisation, envoyez du trafic à l'équilibreur de charge. Pour en savoir plus, consultez les pages suivantes:

Si vous utilisez un équilibreur de charge d'application externe global, consultez Tester le trafic envoyé à vos instances.

Si vous utilisez un équilibreur de charge d'application externe régional, consultez la section Tester l'équilibreur de charge.
Si vous utilisez un équilibreur de charge d'application interne régional, consultez Tester l'équilibreur de charge.

Si vous utilisez un équilibreur de charge d'application interne interrégional, consultez Tester l'équilibreur de charge.

Comprendre les journaux des stratégies d'autorisation dans Cloud Logging

Pour comprendre comment les stratégies d'autorisation sont journalisées lorsqu'une requête est autorisée ou refusée, consultez les documents suivants:

Lorsqu'une requête ne correspond ni aux stratégies ALLOW ni aux stratégies DENY, la stratégie DENY autorise la requête et la consigne en tant que allowed_as_no_deny_policies_matched_request. À l'inverse, la règle ALLOW refuse la requête et la consigne en tant que denied_as_no_allow_policies_matched_request. Étant donné qu'une des règles refuse la requête, celle-ci est refusée.

Si vous utilisez un équilibreur de charge d'application externe global, statusDetails est défini sur denied_by_authz_policy dans le journal. Consultez l'exemple ci-dessous :

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

Si vous utilisez un équilibreur de charge d'application interne régional, un équilibreur de charge d'application externe régional ou un équilibreur de charge d'application interne interrégional, proxyStatus est défini sur error=\"http_request_error\"; details=\"denied_by_authz_policy\" dans le journal. Consultez l'exemple ci-dessous :

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

Lorsqu'une requête correspond à la règle DENY, elle est refusée et la règle qui a refusé la requête est consignée.

Si vous utilisez un équilibreur de charge d'application externe global, statusDetails est défini sur denied_by_authz_policy dans le journal, et le nom de la règle qui a refusé la requête est consigné dans policies. Consultez l'exemple ci-dessous :

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

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

Lorsqu'une requête ne correspond pas à la stratégie DENY, mais qu'elle correspond à la stratégie ALLOW, la requête est autorisée. Dans le journal, cette action est enregistrée en tant que allowed_as_no_deny_policies_matched_request pour la règle DENY. La règle qui a autorisé la requête est également enregistrée.

Si vous utilisez un équilibreur de charge d'application externe global, aucun statusDetails ne figure dans le journal. La stratégie qui a autorisé la requête est également enregistrée dans policies. Consultez l'exemple ci-dessous :

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

Si vous utilisez un équilibreur de charge d'application interne régional, un équilibreur de charge d'application externe régional ou un équilibreur de charge d'application interne interrégional, aucun champ proxyStatus ne s'affiche dans le journal. La stratégie qui a autorisé la requête est également enregistrée dans policies. Consultez l'exemple suivant:

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

Configurer des règles d'autorisation pour les équilibreurs de charge d'application

Avant de commencer

Configurer l'équilibreur de charge

Créer et configurer des tags ou des comptes de service sécurisés

Associer des comptes de service aux VM clientes

Créer les clés et les valeurs de tags sécurisées

Console

gcloud

Lier la balise sécurisée au modèle de groupe d'instances

Créer la règle d'autorisation

Stratégie d'autorisation pour refuser les requêtes

Mondial et interrégional

Régional

Règle d'autorisation pour autoriser les requêtes

Mondial et interrégional

Régional

Stratégie d'autorisation à déléguer à une extension de service

Mondial et interrégional

Régional

Tester les règles d'autorisation

Comprendre les journaux des stratégies d'autorisation dans Cloud Logging

Étape suivante