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

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

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 la page Configurer un équilibreur de charge d'application externe régional avec des backends de groupe 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 associer des comptes de service ou des tags à des VM Google Cloud

Pour les équilibreurs de charge d'application internes, vous pouvez appliquer des règles d'autorisation basées sur des comptes de service ou des tags associés à différentes ressources Google Cloud.

L'exemple de ce document fournit des instructions pour créer une stratégie d'autorisation basée sur des comptes de service ou des tags associés à des instances de machine virtuelle (VM) Google Cloud . Toute requête provenant d'une VM cliente associée à un compte de service ou à une balise spécifique peut être autorisée, refusée ou déléguée à un service externe. Un exemple de stratégie d'autorisation qui utilise des comptes de service et des balises pour appliquer le contrôle des accès est fourni dans la section Stratégie d'autorisation basée sur des comptes de service ou des balises de ce document.

L'application de stratégies d'autorisation basées sur des comptes de service ou des tags n'est pas compatible avec les équilibreurs de charge d'application externes.

Associer des comptes de service aux VM clientes

Pour savoir comment associer 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é.

Associer des tags au modèle de groupe d'instances

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

Créer une clé et une valeur de tag

Pour créer des tags, 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.
```
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 la clé de votre tag.
- ORG_ID : ID de votre organisation.
- LB_NETWORK : nom de votre réseau VPC.
Ajoutez la valeur du tag à 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 au modèle de groupe d'instances

Les administrateurs de tags peuvent lier des tags à 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 lier des tags, 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: votre Google Cloud région.
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: votre Google Cloud région.
- 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 refuser 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.
```
$ 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
```
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: votre Google Cloud région.
- 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 spécifique. 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/regions/LOCATION/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. 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: votre Google Cloud région.
- 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 dans la région LOCATION:
```
gcloud beta network-security authz-policies import my-authz-policy-allow \
    --source=authz-policy-allow.yaml \
    --location=LOCATION
```

Règle d'autorisation basée sur des comptes de service ou des tags

Vous ne pouvez appliquer des règles d'autorisation basées sur des comptes de service ou des tags que sur des équilibreurs de charge d'application internes. Tout trafic provenant d'une VM cliente associée à un compte de service ou à un tag spécifique peut être autorisé, refusé ou délégué à un service externe.

Si vous souhaitez créer et associer des comptes de service ou des tags à des Google Cloud VM, consultez la section Créer et associer des comptes de service ou des tags à des Google Cloud VM de ce document.

Compte de service

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 d'un équilibreur de charge d'application interne régional. La stratégie est configurée pour refuser les requêtes de toutes les VM clientes avec le compte de service my-sa-123@PROJECT_ID.iam.gserviceaccount.com pour accéder au chemin /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:
    - 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 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: votre Google Cloud région.
- 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 la règle d'autorisation dans la région Google Cloud spécifiée.
```
gcloud beta network-security authz-policies import my-authz-policy-deny \
    --source=authz-policy-deny.yaml \
    --location=LOCATION
```
Remplacez les éléments suivants :
- LOCATION: votre Google Cloud région.

Tag

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 d'un équilibreur de charge d'application interne régional. La règle n'autorise que les requêtes provenant d'une VM avec la balise de ressource TAG_VALUE à 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/regions/LOCATION/forwardingRules/LB_FORWARDING_RULE"
httpRules:
- from:
  sources:
    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. Pour 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: votre Google Cloud région.
- 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 dans la régionGoogle Cloud spécifiée:
```
gcloud beta network-security authz-policies import my-authz-policy-allow \
    --source=authz-policy-allow.yaml \
    --location=LOCATION
```
Remplacez les éléments suivants :
- LOCATION: votre Google Cloud région.

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: votre Google Cloud région.
- 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 règles d'autorisation sont journalisées lorsqu'une requête est autorisée ou refusée, consultez les sections suivantes.

La demande ne correspond à aucune des règles `ALLOW` ni `DENY`

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 rejette la requête et la consigne en tant que denied_as_no_allow_policies_matched_request. Étant donné que l'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"
      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"
  }

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

La requête correspond au règlement `DENY`

Lorsqu'une requête correspond à la stratégie DENY, elle est refusée et la stratégie 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"
  }

La requête ne correspond pas au règlement `DENY`, mais au règlement `ALLOW`

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 stratégie qui a autorisé la requête est également enregistrée.

Si vous utilisez un équilibreur de charge d'application externe global, aucun statusDetails n'est indiqué 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/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 figure 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 associer des comptes de service ou des tags à des VM Google Cloud

Associer des comptes de service aux VM clientes

Associer des tags au modèle de groupe d'instances

Créer une clé et une valeur de tag

Console

gcloud

Lier la balise 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

Règle d'autorisation basée sur des comptes de service ou des tags

Compte de service

Tag

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

La demande ne correspond à aucune des règles ALLOW ni DENY

La requête correspond au règlement DENY

La requête ne correspond pas au règlement DENY, mais au règlement ALLOW

Étape suivante

La demande ne correspond à aucune des règles `ALLOW` ni `DENY`

La requête correspond au règlement `DENY`

La requête ne correspond pas au règlement `DENY`, mais au règlement `ALLOW`