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 Network Services

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 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 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 l'importer à l'aide de la commande gcloud network-security authz-policies.

Cette section explique comment créer des règles d'autorisation associées à la règle de transfert des équilibreurs de charge d'application.

Pour savoir comment créer une règle d'autorisation pour une Agent Gateway qui délègue l'autorisation à l'aide de Service Extensions, consultez Déléguer l'autorisation avec Service Extensions.

Pour en savoir plus sur la création d'une stratégie d'autorisation pour un Secure Web Proxy, consultez Configurer des stratégies d'autorisation pour Secure Web Proxy.

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

Cette section fournit des exemples de règles d'autorisation qui refusent les requêtes en fonction de certains attributs de requête.

Refuser les requêtes en fonction de plages d'adresses IP

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

Mondial et interrégional

1. Définissez la stratégie d'autorisation dans un fichier YAML.

   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 l'adresse IP se trouve dans la plage 10.0.0.0/24.

   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:
       - ipBlocks:
         - prefix: "10.0.0.0"
           length: "24"
   - to:
       operations:
       - paths:
         - prefix: "/api/payments"
   action: DENY
   EOF
   

   Remplacez les éléments suivants :

   • LB_SCHEME : schéma d'équilibrage de charge. Pour les équilibreurs de charge d'application externes globaux, définissez le schéma sur EXTERNAL_MANAGED. Pour les équilibreurs de charge d'application internes interrégionaux, 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 la stratégie d'autorisation en important le fichier YAML de la stratégie d'autorisation à l'aide de la commande gcloud network-security authz-policies import.

   gcloud network-security authz-policies import my-authz-policy-deny \
       --source=authz-policy-deny.yaml \
       --location=global
   

Régional

1. Définissez la stratégie d'autorisation dans un fichier YAML.

   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 l'adresse IP se trouve dans la plage 10.0.0.0/24.

   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:
       - ipBlocks:
         - prefix: "10.0.0.0"
           length: "24"
   - to:
       operations:
       - paths:
         - prefix: "/api/payments"
   action: DENY
   EOF
   

   Remplacez les éléments suivants :

   • LB_SCHEME : schéma d'équilibrage de charge. Pour les équilibreurs de charge d'application externes régionaux, définissez le schéma sur EXTERNAL_MANAGED. Pour les équilibreurs de charge d'application internes régionaux, 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 la stratégie d'autorisation en important le fichier YAML de la stratégie d'autorisation à l'aide de la commande gcloud network-security authz-policies import.

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

Refuser les requêtes en fonction des comptes principaux du certificat client

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

Mondial et interrégional

1. Définissez la stratégie d'autorisation dans un fichier YAML.

   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 SAN du nom DNS du certificat client contient www.example.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/global/forwardingRules/LB_FORWARDING_RULE"
   httpRules:
   - from:
       sources:
       - principals:
         - principalSelector: CLIENT_CERT_DNS_NAME_SAN
           principal:
             exact: "www.example.com"
     to:
       operations:
       - paths:
         - prefix: "/api/payments"
   action: DENY
   EOF
   

   Remplacez les éléments suivants :

   • LB_SCHEME : schéma d'équilibrage de charge. Pour les équilibreurs de charge d'application externes globaux, définissez le schéma sur EXTERNAL_MANAGED. Pour les équilibreurs de charge d'application internes interrégionaux, 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 la stratégie d'autorisation en important le fichier YAML de la stratégie d'autorisation à l'aide de la commande gcloud network-security authz-policies import.

   gcloud network-security authz-policies import my-authz-policy-deny \
       --source=authz-policy-deny.yaml \
       --location=global
   

Régional

1. Définissez la stratégie d'autorisation dans un fichier YAML.

   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 SAN du nom DNS du certificat client contient www.example.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"
   policyProfile: REQUEST_AUTHZ
   httpRules:
   - from:
       sources:
       - principals:
         - principalSelector: CLIENT_CERT_DNS_NAME_SAN
           principal:
             exact: "www.example.com"
     to:
       operations:
       - paths:
         - prefix: "/api/payments"
   action: DENY
   EOF
   

   Remplacez les éléments suivants :

   • LB_SCHEME : schéma d'équilibrage de charge. Pour les équilibreurs de charge d'application externes régionaux, définissez le schéma sur EXTERNAL_MANAGED. Pour les équilibreurs de charge d'application internes régionaux, 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 la stratégie d'autorisation en important le fichier YAML de la stratégie d'autorisation à l'aide de la commande gcloud network-security authz-policies import.

   gcloud 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 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 une règle d'autorisation :

1. Définissez la stratégie d'autorisation dans un fichier YAML.

   L'exemple suivant crée un fichier authz-policy-allow.yaml pour la règle de transfert LB_FORWARDING_RULE dans l'emplacement global. La stratégie autorise les clients dont l'adresse IP se trouve dans la plage 10.0.0.0/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.0"
           length: "24"
     to:
       operations:
       - paths:
         - exact: "/api/payments"
   action: ALLOW
   EOF
   

   Remplacez les éléments suivants :

   • LB_SCHEME : schéma d'équilibrage de charge. Pour les équilibreurs de charge d'application externes globaux, définissez le schéma sur EXTERNAL_MANAGED. Pour les équilibreurs de charge d'application internes interrégionaux, 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 la stratégie d'autorisation en important le fichier YAML de la stratégie d'autorisation à l'aide de la commande gcloud network-security authz-policies import.

   gcloud 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, procédez comme suit pour créer et importer une règle d'autorisation :

1. Définissez la stratégie d'autorisation dans un fichier YAML.

   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 stratégie autorise les clients dont l'adresse IP se trouve dans la plage 10.0.0.0/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"
   policyProfile: REQUEST_AUTHZ
   httpRules:
   - from:
       sources:
       - ipBlocks:
         - prefix: "10.0.0.0"
           length: "24"
     to:
       operations:
       - paths:
         - exact: "/api/payments"
   action: ALLOW
   EOF
   

   Remplacez les éléments suivants :

   • LB_SCHEME : schéma d'équilibrage de charge. Pour les équilibreurs de charge d'application externes régionaux, définissez le schéma sur EXTERNAL_MANAGED. Pour les équilibreurs de charge d'application internes régionaux, 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 la stratégie d'autorisation en important le fichier YAML de la stratégie d'autorisation à l'aide de la commande gcloud network-security authz-policies import.

   gcloud 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 pouvez appliquer une stratégie d'autorisation basée sur des comptes de service ou des tags sécurisés associés à différentes ressources Google Cloud .

Cet exemple suppose que vous avez effectué les opérations suivantes :

• créé un compte de service et l'avoir associé à une ressource Google Cloud .

• créé un tag sécurisé et l'avez associé à une ressource Google Cloud sous forme de paire clé-valeur. Lorsque vous créez un tag, définissez son option --purpose sur GCE_FIREWALL. Les règles d'autorisation nécessitent l'objectif GCE_FIREWALL pour appliquer le tag.

Compte de service

1. Définissez la stratégie d'autorisation dans un fichier YAML.

   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 règle est configurée pour refuser les requêtes provenant d'une ressource Google Cloud , telle qu'une VM Compute Engine, 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"
   policyProfile: REQUEST_AUTHZ
   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 : schéma d'équilibrage de charge. Pour les équilibreurs de charge d'application internes régionaux et interrégionaux, 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 la stratégie d'autorisation en important le fichier YAML de la stratégie d'autorisation à l'aide de la commande gcloud network-security authz-policies import.

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

   Remplacez LOCATION par votre région Google Cloud .

Tag

1. Définissez la stratégie d'autorisation dans un fichier YAML.

   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 ressource Google Cloud , telle qu'une VM Compute Engine, avec une valeur de tag sécuriséTAG_VALUE_PERMANENT_ID pour 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"
   policyProfile: REQUEST_AUTHZ
   httpRules:
   - from:
     sources:
       resources:
       - tagValueIdSet:
         - ids: "TAG_VALUE_PERMANENT_ID"
     to:
       operations:
       - paths:
         - exact: "/api/payments"
   action: ALLOW
   EOF
   

   Remplacez les éléments suivants :

   • LB_SCHEME : schéma d'équilibrage de charge. Pour les équilibreurs de charge d'application internes régionaux et interrégionaux, 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.
   • TAG_VALUE_PERMANENT_ID : ID permanent d'une valeur de tag.

2. Créez la stratégie d'autorisation en important le fichier YAML de la stratégie d'autorisation à l'aide de la commande gcloud network-security authz-policies import.

   gcloud 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 pour déléguer les décisions d'autorisation

Les exemples de cette section créent une stratégie d'autorisation qui délègue les décisions d'autorisation aux services suivants via les extensions de service :

• Service géré par l'utilisateur
  • un Google Cloud service de backend ou un service basé sur un nom de domaine complet
• Service géré par Google
  • Model Armor
  • Identity-Aware Proxy

Déléguer la décision d'autorisation à un service géré par l'utilisateur

Vous pouvez configurer une règle d'autorisation pour déléguer la décision d'autorisation à un service géré par l'utilisateur via des extensions de service, en particulier une extension d'autorisation.

• Pour les équilibreurs de charge globaux et interrégionaux, l'extension d'autorisation peut s'exécuter sur un service de backend Google Cloud géré par l'utilisateur.

• Pour les équilibreurs de charge régionaux, l'extension d'autorisation peut s'exécuter à la fois sur un service de backend Google Cloud géré par l'utilisateur et sur un service basé sur un FQDN.

Cet exemple de configuration suppose que vous avez créé un service de backend Google Cloud géré par l'utilisateur, également appelé service de backend de callout, nommé authz-service. Pour savoir comment en créer un, consultez Configurer un service de backend de légende géré par l'utilisateur.

Pour un service basé sur un nom de domaine complet, cet exemple de configuration suppose que le service personnalisé est déployé dans votre propre VPC, qu'il est compatible avec le protocole ext_authz et qu'il est accessible par le nom de domaine complet mycustomauthz.internal.net.

Remarque : Lorsque vous faites pointer une extension d'autorisation vers un domaine (FQDN), l'équilibreur de charge utilise le protocole HTTP/2 avec chiffrement TLS pour communiquer avec les points de terminaison sur le port 443. Toutefois, même si le trafic est chiffré, l'équilibreur de charge ne valide pas le certificat du serveur. Cela signifie qu'il accepte tout certificat fourni par le serveur, même s'il est expiré, autosigné ou destiné à un autre domaine. Pour vous assurer que l'équilibreur de charge ne communique qu'avec des services de confiance, vérifiez que le nom de domaine complet correspond à une adresse IP de votre environnement VPC.

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, suivez ces étapes pour déléguer la décision d'autorisation au service géré par l'utilisateur.

1. Définissez l'extension d'autorisation dans un fichier YAML. L'extension d'autorisation s'exécute sur un service de backend (authz-service) et est compatible avec le protocole ext_authz.

   cat >authz-extension.yaml <<EOF
   name: my-authz-ext
   authority: ext11.com
   loadBalancingScheme: LB_SCHEME
   service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/authz-service
   forwardHeaders:
     - Authorization
   failOpen: false
   timeout: "0.1s"
   wireFormat: EXT_AUTHZ_GRPC
   EOF
   

2. Créez l'extension d'autorisation en important le fichier YAML de l'extension d'autorisation à l'aide de la commande gcloud service-extensions authz-extensions import.

   gcloud service-extensions authz-extensions import my-authz-ext \
       --source=authz-extension.yaml \
       --location=global
   

   Remplacez les éléments suivants :

   • LB_SCHEME : schéma d'équilibrage de charge. Pour les équilibreurs de charge d'application externes globaux, définissez le schéma sur EXTERNAL_MANAGED. Pour les équilibreurs de charge d'application internes interrégionaux, définissez le schéma sur INTERNAL_MANAGED.
   • PROJECT_ID : ID de votre projet Google Cloud .

3. Définissez la stratégie d'autorisation dans un fichier YAML. La règle d'autorisation délègue l'autorisation à l'extension d'autorisation dans le champ customProvider.

   La règle appelle l'extension d'autorisation my-authz-ext pour tout le trafic vers le chemin d'URL example.com/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:
       - hosts:
         - exact: "example.com"
       - paths:
         - exact: "/api/payments"
     when: 'request.headers["Authorization"] != ""'
   action: CUSTOM
   customProvider:
     authzExtension:
       resources:
       - "projects/PROJECT_ID/locations/global/authzExtensions/my-authz-ext"
   EOF
   

   Remplacez les éléments suivants :

   • LB_SCHEME : schéma d'équilibrage de charge. Pour les équilibreurs de charge d'application externes globaux, définissez le schéma sur EXTERNAL_MANAGED. Pour les équilibreurs de charge d'application internes interrégionaux, 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.

4. Créez la règle d'autorisation en important le fichier YAML de la règle d'autorisation à l'aide de la commande gcloud network-security authz-policies import.

   gcloud 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 déléguer la décision d'autorisation à un service géré par l'utilisateur.

1. Définissez l'extension d'autorisation dans un fichier YAML. L'extension d'autorisation peut s'exécuter sur un service de backend ou un service basé sur un FQDN.

   cat >authz-extension.yaml <<EOF
   name: my-authz-ext
   authority: ext11.com
   loadBalancingScheme: LB_SCHEME
   service: BACKEND_SERVICE_URI_OR_FQDN
   forwardHeaders:
     - Authorization
   failOpen: false
   timeout: "0.1s"
   wireFormat: EXT_AUTHZ_GRPC
   EOF
   

   Remplacez les éléments suivants :

   • LB_SCHEME : schéma d'équilibrage de charge. Pour les équilibreurs de charge d'application externes régionaux, définissez le schéma sur EXTERNAL_MANAGED. Pour les équilibreurs de charge d'application internes régionaux, définissez le schéma sur INTERNAL_MANAGED.
   • BACKEND_SERVICE_URI_OR_FQDN : le service peut être l'un des suivants :
     • URI de ressource de service de backend régional au format https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/LOCATION/backendServices/authz-service.
     • un nom de domaine complet (par exemple, mycustomauthz.extension.net) pouvant être résolu par Cloud DNS.

2. Créez l'extension d'autorisation en important le fichier YAML de l'extension d'autorisation à l'aide de la commande gcloud service-extensions authz-extensions import.

   gcloud service-extensions authz-extensions import my-authz-ext \
       --source=authz-extension.yaml \
       --location=LOCATION
   

   Remplacez LOCATION par la région Google Cloudoù le service de backend de l'appel est configuré.

3. Définissez la stratégie d'autorisation dans un fichier YAML. La stratégie d'autorisation délègue l'autorisation à l'extension d'autorisation dans le champ customProvider.

   La stratégie appelle l'extension d'autorisation my-authz-ext pour tout le trafic vers le chemin d'URL example.com/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"
   policyProfile: REQUEST_AUTHZ
   httpRules:
   - to:
       operations:
       - paths:
         - exact: "/api/payments"
     when: 'request.headers["Authorization"] != ""'
   action: CUSTOM
   customProvider:
     authzExtension:
       resources:
       - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-authz-ext"
   EOF
   

   Remplacez les éléments suivants :

   • LB_SCHEME : schéma d'équilibrage de charge. Pour les équilibreurs de charge d'application externes régionaux, définissez le schéma sur EXTERNAL_MANAGED. Pour les équilibreurs de charge d'application internes régionaux, 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.

4. Créez la règle d'autorisation en important le fichier YAML de la règle d'autorisation à l'aide de la commande gcloud network-security authz-policies import.

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

   Remplacez LOCATION par la région Google Cloudoù l'équilibreur de charge est configuré.

Pour en savoir plus sur les extensions d'autorisation, consultez Configurer une extension d'autorisation.

Déléguer la décision d'autorisation à Model Armor

Vous pouvez configurer une règle d'autorisation pour déléguer la décision d'autorisation à Model Armor.

Avant de commencer, créez un modèle Model Armor. Dans cet exemple de configuration, la stratégie d'autorisation pointe vers une extension d'autorisation, qui pointe à son tour vers Model Armor.

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 déléguer la décision d'autorisation à Model Armor.

Régional

1. Définissez l'extension d'autorisation dans un fichier YAML. L'extension d'autorisation pointe vers les modèles de requête et de réponse Model Armor.

   cat >authz-extension.yaml <<EOF
   name: my-authz-extension
   loadBalancingScheme: INTERNAL_MANAGED
   service: modelarmor.LOCATION.rep.googleapis.com
   metadata:
     model_armor_settings: '[
       {
       "response_template_id": "projects/PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID",
       "request_template_id": "projects/PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID"
       }
     ]'
   failOpen: true
   EOF
   

   Remplacez les éléments suivants :

   • LOCATION : emplacement du modèle
   • PROJECT_ID : ID du projet auquel appartient le modèle
   • RESPONSE_TEMPLATE_ID : ID du modèle de réponse
   • REQUEST_TEMPLATE_ID : ID du modèle de requête

2. Créez l'extension d'autorisation en important le fichier YAML de l'extension d'autorisation à l'aide de la commande gcloud service-extensions authz-extensions import.

   gcloud service-extensions authz-extensions import my-authz-ext \
     --source=authz-extension.yaml \
     --location=LOCATION
   

   Remplacez LOCATION par la région Google Cloudoù se trouve l'équilibreur de charge.

3. Définissez la stratégie d'autorisation dans un fichier YAML. La stratégie d'autorisation délègue l'autorisation à l'extension d'autorisation dans le champ customProvider.

   La valeur de policyProfile est CONTENT_AUTHZ.

   cat >authz-policy-custom.yaml <<EOF
   name: my-authz-policy-custom
   target:
     loadBalancingScheme: INTERNAL_MANAGED
     resources:
     - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/LOCATION/forwardingRules/LB_FORWARDING_RULE"
   policyProfile: CONTENT_AUTHZ
   action: CUSTOM
   customProvider:
     authzExtension:
       resources:
       - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-authz-ext"
   EOF
   

   Remplacez les éléments suivants :

   • 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.

4. Créez la règle d'autorisation en important le fichier YAML de la règle d'autorisation à l'aide de la commande gcloud network-security authz-policies import.

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

   Remplacez LOCATION par la région Google Cloudoù l'équilibreur de charge est configuré.

Déléguer la décision d'autorisation à Identity-Aware Proxy

Pour les équilibreurs de charge d'application externes globaux et les équilibreurs de charge d'application internes interrégionaux, vous ne pouvez pas déléguer la décision d'autorisation à IAP via une extension d'autorisation. Pour ces équilibreurs de charge, vous pouvez déléguer la décision d'autorisation à IAP via le champ customProvider de la ressource de stratégie d'autorisation.

Pour les équilibreurs de charge d'application externes régionaux et les équilibreurs de charge d'application internes régionaux, vous pouvez configurer une stratégie d'autorisation pour déléguer la décision d'autorisation à IAP via une extension d'autorisation.

Mondial et interrégional

Dans l'exemple suivant, toutes les décisions d'autorisation sont déléguées à IAP pour toutes les requêtes provenant du bloc d'adresses IP 10.0.0.0/24. Si les requêtes proviennent d'une adresse IP en dehors de 10.0.0.0/24, elles ne correspondent pas à cette stratégie et ne sont pas évaluées par IAP selon cette règle spécifique.

1. Définissez la stratégie d'autorisation dans un fichier YAML. La stratégie d'autorisation délègue l'autorisation à IAP via le champ customProvider.

   cat >authz-policy-iap.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:
     - from:
         sources:
         - ipBlock:
           - prefix: "10.0.0.0"
             length: 24
   action: CUSTOM
   customProvider:
     cloudIap: {}
   EOF
   

   Remplacez les éléments suivants :

   • LB_SCHEME : schéma d'équilibrage de charge. Pour les équilibreurs de charge d'application externes globaux, définissez le schéma sur EXTERNAL_MANAGED. Pour les équilibreurs de charge d'application internes interrégionaux, 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 la règle d'autorisation en important le fichier YAML de la règle d'autorisation à l'aide de la commande gcloud network-security authz-policies import.

   gcloud network-security authz-policies import my-authz-policy-custom \
       --source=authz-policy-iap.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 déléguer la décision d'autorisation à IAP à l'aide d'une extension d'autorisation.

1. Définissez l'extension d'autorisation dans un fichier YAML. L'extension d'autorisation pointe vers IAP.

   cat >authz-extension.yaml <<EOF
   name: my-authz-ext
   loadBalancingScheme: LB_SCHEME
   service: iap.googleapis.com
   failOpen: false
   EOF
   

   Remplacez les éléments suivants :

   • LB_SCHEME : schéma d'équilibrage de charge. Pour les équilibreurs de charge d'application externes régionaux, définissez le schéma sur EXTERNAL_MANAGED. Pour les équilibreurs de charge d'application internes régionaux, définissez le schéma sur INTERNAL_MANAGED.

2. Créez l'extension d'autorisation en important le fichier YAML de l'extension d'autorisation à l'aide de la commande gcloud service-extensions authz-extensions import.

   gcloud service-extensions authz-extensions import my-authz-ext \
       --source=authz-extension.yaml \
       --location=LOCATION
   

   Remplacez LOCATION par la région Google Cloudoù l'extension d'autorisation est configurée.

3. Définissez la stratégie d'autorisation dans un fichier YAML. La stratégie d'autorisation délègue l'autorisation à l'extension d'autorisation dans le champ customProvider.

   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"
   policyProfile: REQUEST_AUTHZ
   action: CUSTOM
   customProvider:
     authzExtension:
       resources:
       - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-authz-ext"
   EOF
   

   Remplacez les éléments suivants :

   • LB_SCHEME : schéma d'équilibrage de charge. Pour les équilibreurs de charge d'application externes régionaux, définissez le schéma sur EXTERNAL_MANAGED. Pour les équilibreurs de charge d'application internes régionaux, 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.

4. Créez la règle d'autorisation en important le fichier YAML de la règle d'autorisation à l'aide de la commande gcloud network-security authz-policies import.

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

   Remplacez LOCATION par la région Google Cloudoù l'équilibreur de charge est configuré.

Comprendre les journaux des règles 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 requête ne correspond ni à la règle ALLOW, ni à la règle DENY

Lorsqu'une requête ne correspond ni à la règle ALLOW, ni à la règle DENY, la règle DENY l'autorise et l'enregistre en tant que allowed_as_no_deny_policies_matched_request. À l'inverse, la règle ALLOW refuse la requête et l'enregistre 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 requête 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 stratégie 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 stratégie 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 requête ne correspond pas à la règle DENY, mais correspond à la règle 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 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 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'est pas présent 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

• Configurer une extension d'autorisation

• Déléguer l'autorisation à IAP et IAM