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

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 :

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 explique comment créer une règle 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 à un tag spécifique peut être autorisée, refusée ou déléguée à un service externe. Un exemple de stratégie d'autorisation utilisant des comptes de service et des tags 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 tags 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 à des VM clientes

Pour savoir comment associer un compte de service à une instance de VM, consultez les documents suivants :

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

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

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

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

    Accéder aux balises

  2. Cliquez sur  Créer.

  3. Dans le champ Description de la clé de tag, saisissez une description.

  4. Cochez la case À utiliser avec le pare-feu du réseau.

  5. Dans la liste Projet, sélectionnez le projet Google Cloud dans lequel vous souhaitez créer le tag.

  6. Dans le champ Réseau, sélectionnez LB_NETWORK.

  7. Cliquez sur Ajouter une valeur.

  8. Dans le champ Valeur du tag, saisissez TAG_VALUE. La valeur doit être numérique.

  9. Dans le champ Description de la valeur de tag, saisissez une description.

  10. Lorsque vous avez terminé d'ajouter des valeurs de tag, cliquez sur Créer une clé de tag.

gcloud

  1. 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é du tag.
    • ORG_ID : ID de votre organisation.
    • LB_NETWORK : nom de votre réseau VPC.

  2. 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 numérique de tag.

Associer le tag 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).

  1. 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é.

  2. 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 région Google Cloud .

  3. Concaténez les valeurs de FULL_NAME_PREFIX et de TEMPLATE_ID :

    PARENT="$FULL_NAME_PREFIX$TEMPLATE_ID"
echo $PARENT

  4. 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 région Google Cloud .
    • TAG_KEY : nom de votre clé de tag sécurisée.
    • TAG_VALUE : valeur numérique du tag.

Créer une règle d'autorisation

Pour créer une règle 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.

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

Cette section fournit un exemple de stratégie d'autorisation qui refuse les requêtes en fonction des noms principaux du certificat client.

Mondial et multirégional

Si vous utilisez un équilibreur de charge d'application externe global ou un équilibreur de charge d'application interne interrégional, suivez ces étapes pour créer et importer une règle d'autorisation :

  1. Créez un fichier YAML de règle 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 l'emplacement global. La règle refuse l'accès au chemin d'URL /api/payments aux clients dont le nom DNS du certificat client contient www.example.com dans les SAN.

    $ 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

    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.

  2. Créez une règle d'autorisation et importez le fichier YAML.

    L'exemple de commande suivant importe le fichier de stratégie précédemment créé et crée une stratégie 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, suivez ces étapes pour créer et importer une règle d'autorisation :

  1. Créez un fichier YAML de règle 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égionGoogle Cloud . La règle refuse l'accès au chemin d'URL /api/payments aux clients dont le nom DNS du certificat client contient www.example.com dans les SAN.

    $ 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

    Remplacez les éléments suivants :

    • LB_SCHEME : votre schéma d'équilibrage de charge. Pour un équilibreur de charge d'application externe régional, définissez le schéma sur EXTERNAL_MANAGED. 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 région Google Cloud .
    • LB_FORWARDING_RULE : nom de la règle de transfert de l'équilibreur de charge.

  2. Créez une règle 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 une règle 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

Cette section fournit un exemple de stratégie d'autorisation qui autorise les requêtes provenant de plages d'adresses IP spécifiques.

Mondial et multirégional

Si vous utilisez un équilibreur de charge d'application externe global ou un équilibreur de charge d'application interne interrégional, suivez ces étapes pour créer et importer une règle d'autorisation :

  1. Créez un fichier YAML de règle 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 autorise les clients dont l'adresse IP se trouve dans la plage 10.0.0.1/24 à 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:
    - ipBlocks:
      - prefix: "10.0.0.1"
        length: "24"
  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.

  2. Créez une règle d'autorisation et importez le fichier YAML.

    L'exemple de commande suivant importe le fichier de règle créé précédemment et crée une règle d'autorisation :

    gcloud beta network-security authz-policies import my-authz-policy-allow \
    --source=authz-policy-allow.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, suivez ces étapes pour créer et importer une règle d'autorisation :

  1. Créez un fichier YAML de règle 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 autorise les clients dont l'adresse IP se trouve dans la plage 10.0.0.1/24 à 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:
    - ipBlocks:
      - prefix: "10.0.0.1"
        length: "24"
  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 région Google Cloud .
    • LB_FORWARDING_RULE : nom de la règle de transfert de l'équilibreur de charge.

  2. Créez une règle 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 une règle 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 qu'aux é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 VM Google Cloud , consultez la section Créer et associer des comptes de service ou des tags à des VM Google Cloud de ce document.

Compte de service

  1. Créez un fichier YAML de règle 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 atteindre le chemin d'accès /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 région Google Cloud .
    • LB_FORWARDING_RULE : nom de la règle de transfert de l'équilibreur de charge.

  2. Créez une règle 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 une 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 région Google Cloud .

Tag

  1. Créez un fichier YAML de règle 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 le tag 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 région Google Cloud .
    • LB_FORWARDING_RULE : nom de la règle de transfert de l'équilibreur de charge.

  2. Créez une règle 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 une règle 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 région Google Cloud .

Règle 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 callouts Cloud Load Balancing.

Mondial et multirégional

Si vous utilisez un équilibreur de charge d'application externe global ou un équilibreur de charge d'application interne interrégional, suivez ces étapes pour créer et importer une règle d'autorisation :

  1. Créez un 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 à 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.

  2. Créez une règle d'autorisation et importez le fichier YAML.

    L'exemple de commande suivant importe le fichier de stratégie précédemment créé et crée une stratégie d'autorisation :

    gcloud beta network-security authz-policies import my-authz-policy-custom \
    --source=authz-policy-custom.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, suivez ces étapes pour créer et importer une règle d'autorisation :

  1. Créez un fichier YAML de règle 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 un équilibreur de charge d'application externe régional, définissez le schéma sur EXTERNAL_MANAGED. 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 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.

  2. Créez une règle 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 une règle 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 une règle d'autorisation

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

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

Pour comprendre comment les règles d'autorisation sont consignées lorsqu'une requête est autorisée ou refusée, consultez les sections suivantes.

La demande ne correspond ni au règlement ALLOW ni au règlement DENY

Lorsqu'une requête ne correspond à aucune des stratégies ALLOW ni 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. Comme 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 demande correspond à la règle DENY

Lorsqu'une requête correspond à la règle DENY, elle est refusée et la règle qui l'a refusée 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"
  }

  • 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\" et le nom de la règle 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/$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 demande ne correspond pas au règlement DENY, mais correspond au règlement ALLOW

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

  • Si vous utilisez un équilibreur de charge d'application externe global, il n'y a pas de statusDetails dans le journal. La règle qui a autorisé la requête est également consigné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, le champ proxyStatus n'apparaît pas dans le journal. La stratégie qui a autorisé la requête est également consigné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"
  }

Étapes suivantes