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 Configurer un équilibreur de charge d'application externe régional avec des backends de groupes d'instances de VM.

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

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

Créer 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 network-security authz-policies.

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

Pour en savoir plus sur la création d'une règle d'autorisation pour un Agent Gateway qui délègue l'autorisation à l'aide de Service Extensions, consultez Déléguer l'autorisation avec Service Extensions.

Pour savoir comment créer une règle d'autorisation pour un proxy Web sécurisé, consultez Configurer des règles d'autorisation pour Secure Web Proxy.

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

Cette section fournit des exemples de stratégies d'autorisation qui refusent les requêtes en fonction de certains attributs de requête.

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

Cette section fournit un exemple de règle d'autorisation qui refuse les requêtes en fonction des requêtes provenant de plages d'adresses IP spécifiques.

Mondial et multirégional

1. Définissez la règle 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 à l'emplacement global. La règle refuse aux clients dont l'adresse IP se trouve dans la plage 10.0.0.0/24 l'accès au chemin de l'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:
       - 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 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-deny \
       --source=authz-policy-deny.yaml \
       --location=global
   

Régional

1. Définissez la règle 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 . Cette règle refuse aux clients dont l'adresse IP se trouve dans la plage 10.0.0.0/24 l'accès au chemin de l'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:
       - 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 .
   • 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-deny \
       --source=authz-policy-deny.yaml \
       --location=global
   

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

Cette section fournit un exemple de règle d'autorisation qui refuse les requêtes en fonction des principaux du certificat client.

Mondial et multirégional

1. Définissez la règle 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 de l'URL /api/payments aux clients dont le nom DNS SAN 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 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-deny \
       --source=authz-policy-deny.yaml \
       --location=global
   

Régional

1. Définissez la règle 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 de l'URL /api/payments aux clients dont le nom DNS du certificat client SAN 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 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 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 une règle d'autorisation :

1. Définissez la règle 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 à l'emplacement global. La règle 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 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-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. Définissez la règle 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 règle autorise les clients dont l'adresse IP se trouve dans la plage 10.0.0.0/24 à accéder au chemin de l'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 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 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 pouvez appliquer une règle 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 :

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

• créé un tag sécurisé et l'a associé à une ressource Google Cloud sous la forme d'une paire clé/valeur. Lorsque vous créez un tag, définissez son indicateur --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 règle 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 d'une ressource Google Cloud , telle qu'une VM Compute Engine, avec le compte de servicemy-sa-123@PROJECT_ID.iam.gserviceaccount.com pour accéder au 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 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 beta 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 règle 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ée TAG_VALUE_PERMANENT_ID pour accéder au chemin de l'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 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 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 permettant de déléguer les décisions d'autorisation

Les exemples de cette section créent une règle 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 service de backendGoogle Cloud 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 Service Extensions, en particulier une extension d'autorisation.

• Pour les équilibreurs de charge mondiaux 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 nom de domaine complet.

Cette configuration d'exemple suppose que vous avez créé un service de backend Google Cloud géré par l'utilisateur, également appelé service de backend d'appel, nommé authz-service. Pour savoir comment en créer un, consultez Configurer un service de backend d'appel 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 pointez une extension d'autorisation vers un domaine (FQDN), l'équilibreur de charge utilise le protocole HTTP/2 avec le 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, assurez-vous que le nom de domaine complet est associé à une adresse IP dans votre environnement VPC.

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 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 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 mondiaux, 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 règle 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 de l'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 mondiaux, 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 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 nom de domaine complet.

   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) qui peut ê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 Clouddans laquelle le service de backend d'appel est configuré.

3. Définissez la règle 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 de l'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 règle d'autorisation à l'aide de la commande gcloud network-security authz-policies import.

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

   Remplacez LOCATION par la région Google Clouddans laquelle 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 règle d'autorisation pointe vers une extension d'autorisation, qui à son tour pointe 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 demande

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

   gcloud beta 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 règle 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 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 règle d'autorisation à l'aide de la commande gcloud beta network-security authz-policies import.

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

   Remplacez LOCATION par la région Google Clouddans laquelle 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 règle 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 règle d'autorisation afin de déléguer la décision d'autorisation à IAP via une extension d'autorisation.

Mondial et multiré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 règle et ne sont pas évaluées par IAP dans le cadre de cette règle spécifique.

1. Définissez la règle d'autorisation dans un fichier YAML. La règle 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 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 règle d'autorisation dans un fichier YAML. La règle 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 règle d'autorisation à l'aide de la commande gcloud network-security authz-policies import.

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

   Remplacez LOCATION par la région Google Clouddans laquelle 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 demande ne correspond ni au règlement ALLOW ni au règlement DENY

Lorsqu'une requête ne correspond à aucune des règles ALLOW ni DENY, la règle 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 au règlement 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 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'apparaît pas 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/$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