Présentation des règles d'autorisation

Les règles d'autorisation vous permettent d'établir des vérifications du contrôle des accès et de l'assainissement du contenu lors du traitement des requêtes ou des réponses via différents servicesGoogle Cloud , tels que les équilibreurs de charge d'application, Agent Gateway (aperçu privé) et Secure Web Proxy.

Pour Agent Gateway et Secure Web Proxy, la règle d'autorisation est associée directement à la ressource de passerelle de ces services. Pour un équilibreur de charge, la règle d'autorisation est associée à la ressource de règle de transfert de l'équilibreur de charge.

Remarque : Bien que certaines parties de ce document se concentrent sur les règles d'autorisation en relation avec Cloud Load Balancing, les concepts de règles d'autorisation abordés ici s'appliquent à tous les services Google Cloud mentionnés ci-dessus.

Une règle d'autorisation (AuthzPolicy) associée à la règle de transfert d'un équilibreur de charge vous permet de spécifier des conditions qui autorisent, restreignent ou délèguent l'autorisation des requêtes en fonction de leur source et des opérations prévues. Les requêtes qui réussissent ces vérifications sont acheminées vers le service de backend de l'équilibreur de charge, tandis que celles qui échouent sont refusées avec une réponse non autorisée.

Vous pouvez configurer des règles d'autorisation sur la règle de transfert de tous les équilibreurs de charge d'application avec un schéma d'équilibrage de charge EXTERNAL_MANAGED ou INTERNAL_MANAGED. Les équilibreurs de charge d'application suivants sont compatibles avec les règles d'autorisation :

• Équilibreurs de charge d'application externes globaux

• Équilibreurs de charge d'application externes régionaux
• Équilibreurs de charge d'application internes régionaux

• Équilibreurs de charge d'application internes interrégionaux

Règles d'autorisation

Une règle d'autorisation se compose d'une liste de règles HTTP à mettre en correspondance avec la requête entrante.

Pour une règle d'autorisation avec une action ALLOW ou DENY, une règle HTTP (AuthzRule) définit les conditions qui déterminent si le trafic est autorisé à transiter par l'équilibreur de charge. Vous devez ajouter au moins une règle HTTP.

Pour une règle d'autorisation avec une action CUSTOM, une règle HTTP (AuthzRule) définit les conditions qui déterminent si le trafic est délégué au fournisseur personnalisé pour l'autorisation. Un fournisseur personnalisé est requis, tandis que les règles HTTP sont facultatives.

Une correspondance de règle se produit lorsqu'au moins une règle HTTP correspond à la requête ou lorsqu'aucune règle HTTP n'est définie dans la règle.

Une règle HTTP de stratégie d'autorisation se compose des champs suivants :

• from : spécifie l'identité du client autorisé par la règle. L'identité peut être dérivée d'un certificat client dans une connexion TLS mutuelle, ou il peut s'agir de l'identité ambiante associée à l'instance de machine virtuelle (VM) cliente, par exemple à partir d'un compte de service ou d'un tag sécurisé.
• to : spécifie les opérations autorisées par la règle, telles que les URL accessibles ou les méthodes HTTP autorisées.
• when : spécifie les contraintes supplémentaires à respecter. Vous pouvez utiliser des expressions CEL (Common Expression Language) pour définir les contraintes.

Actions des règles d'autorisation

Lors de l'évaluation d'une requête, une règle d'autorisation spécifie l'action (AuthzAction) à appliquer à la requête. Une règle d'autorisation doit comporter au moins une action, qui peut être l'une des suivantes :

• ALLOW : permet à la requête de passer au backend si elle correspond à l'une des règles spécifiées dans une stratégie ALLOW. S'il existe des règles ALLOW, mais qu'aucune ne correspond, la requête est refusée. En d'autres termes, la requête est refusée si aucune des règles d'autorisation configurées avec une action ALLOW ne correspond à la requête. Dans Cloud Logging, cette action est consignée sous la forme denied_as_no_allow_policies_matched_request.

  Pour qu'une action ALLOW soit appliquée, vous devez définir au moins une règle HTTP.

• DENY : refuse la requête si elle correspond à l'une des règles spécifiées dans une stratégie DENY. S'il existe des règles DENY, mais qu'aucune ne correspond, la requête est autorisée. En d'autres termes, la requête est autorisée si aucune des stratégies d'autorisation configurées avec une action DENY ne correspond à la requête. Dans Cloud Logging, cette action est consignée sous la forme allowed_as_no_deny_policies_matched_request.

  Pour qu'une action DENY soit appliquée, vous devez disposer d'au moins une règle HTTP.

• CUSTOM : délègue la décision d'autorisation à un fournisseur d'autorisation personnalisé, tel qu'IAP ou les extensions de service. Pour en savoir plus, consultez Déléguer les décisions d'autorisation.

  Si des règles HTTP sont configurées pour une règle CUSTOM, la requête doit correspondre aux règles HTTP pour appeler le fournisseur personnalisé. Toutefois, si aucune règle HTTP n'est définie, la règle d'autorisation délègue toujours la décision d'autorisation à un fournisseur d'autorisation personnalisé. Pour en savoir plus, consultez les exemples dans Stratégie d'autorisation pour déléguer les décisions d'autorisation.

Ordre d'évaluation des règles d'autorisation

Une règle d'autorisation est compatible avec les règles CUSTOM, DENY et ALLOW pour le contrôle des accès. Lorsque plusieurs règles d'autorisation sont associées à une même ressource, la règle CUSTOM est évaluée en premier, suivie de la règle DENY, puis de la règle ALLOW. L'évaluation est déterminée par les règles suivantes :

1. S'il existe une règle CUSTOM qui correspond à la requête, elle est évaluée à l'aide d'un fournisseur d'autorisation personnalisé.CUSTOM Si le fournisseur personnalisé refuse la demande, celle-ci est refusée. Les règles DENY ou ALLOW ne sont pas évaluées, même si certaines sont configurées.

2. S'il existe des règles DENY correspondant à la requête, celle-ci est refusée. Les règles ALLOW ne sont pas évaluées, même si elles sont configurées.

3. Si aucune règle ALLOW n'existe, la requête est autorisée.

4. Si l'une des règles ALLOW correspond à la requête, autorisez-la.

5. S'il existe des règles ALLOW, mais qu'aucune ne correspond, la requête est refusée. En d'autres termes, la requête est refusée par défaut si aucune des AuthzPolicies configurées avec l'action ALLOW ne correspond à la requête.

Pour les équilibreurs de charge d'application externes régionaux, les équilibreurs de charge d'application internes régionaux, Agent Gateway et Secure Web Proxy (servicesGoogle Cloud compatibles avec les profils de règles), l'ordre d'évaluation des règles d'autorisation est le suivant :

1. S'il existe une règle d'autorisation de requête personnalisée (REQUEST_AUTHZ) qui correspond à la requête, la règle REQUEST_AUTHZ est évaluée à l'aide d'un fournisseur d'autorisation personnalisé. Si le fournisseur personnalisé refuse la demande, celle-ci est refusée. Les règles DENY, ALLOW et CONTENT_AUTHZ ne sont pas évaluées, même si certaines sont configurées.

2. S'il existe des règles DENY correspondant à la requête, celle-ci est refusée. Les règles ALLOW et CONTENT_AUTHZ ne sont pas évaluées, même si elles sont configurées.

3. S'il n'existe aucune règle ALLOW, la requête passe à l'évaluation de l'autorisation de contenu (CONTENT_AUTHZ).

4. Si l'une des règles ALLOW correspond à la requête, celle-ci passe à l'évaluation CONTENT_AUTHZ.

5. S'il existe des règles ALLOW, mais qu'aucune ne correspond, la requête est refusée. Les règles CONTENT_AUTHZ ne sont pas évaluées.

6. Si une règle CONTENT_AUTHZ correspond à la requête, elle est évaluée en dernier. Si le fournisseur personnalisé refuse la demande, celle-ci est refusée.

Profils de règles dans les règles d'autorisation

Aperçu

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Les profils de règles dans les règles d'autorisation sont compatibles avec les services Google Cloud suivants :

• Équilibreurs de charge d'application externes régionaux
• Équilibreurs de charge d'application internes régionaux
• Passerelle d'agent
• Proxy Web sécurisé

Un profil de règle (PolicyProfile) dans une règle d'autorisation est l'un des types suivants :

• Profil d'autorisation des requêtes (REQUEST_AUTHZ) : s'appuie sur les informations contenues dans les en-têtes de requête HTTP pour autoriser ou refuser le trafic.
• Profil d'autorisation de contenu (CONTENT_AUTHZ) : fournit une sécurité et un filtrage basés sur le contenu pour bloquer les attaques par injection de prompt, empêcher les fuites de données sensibles et filtrer les contenus nuisibles.

Vous pouvez configurer une règle d'autorisation avec un profil REQUEST_AUTHZ ou un profil CONTENT_AUTHZ, mais pas les deux. Si aucun profil de règle n'est spécifié, la règle d'autorisation utilise le profil REQUEST_AUTHZ par défaut.

Demander un profil d'autorisation

Les règles d'autorisation utilisant le profil de règle REQUEST_AUTHZ peuvent évaluer les décisions d'accès pour le trafic entrant directement ou en les déléguant. Vous pouvez déléguer les décisions d'accès à Identity-Aware Proxy ou à un moteur d'autorisation personnalisé à l'aide d'une extension d'autorisation. Le profil de règle REQUEST_AUTHZ agit sur les informations contenues dans les en-têtes de requête HTTP pour autoriser ou refuser une requête.

Une règle d'autorisation avec le profil de règle REQUEST_AUTHZ peut avoir une action ALLOW, DENY ou CUSTOM appliquée à la requête. Une action ALLOW ou DENY signifie que la décision d'accès est évaluée directement, tandis qu'une action CUSTOM signifie que la décision d'accès est déléguée.

Lorsque la décision d'accès est déléguée, une règle d'autorisation configurée sur la règle de transfert de l'équilibreur de charge pointe vers une extension d'autorisation de requête qui s'exécute sur un service de backend d'appel. Pour chaque demande d'autorisation, l'équilibreur de charge transfère les en-têtes de requête à l'extension d'autorisation à l'aide du protocole ext_proc ou ext_authz d'Envoy. En fonction de la réponse de l'extension, le proxy de l'équilibreur de charge transfère la requête à son service de backend ou la refuse.

Si aucun profil de règle n'est spécifié, la règle d'autorisation utilise par défaut le profil d'autorisation de la requête (REQUEST_AUTHZ).

Profil d'autorisation de contenu

Les règles d'autorisation utilisant le profil de règle CONTENT_AUTHZ peuvent être utilisées pour effectuer une inspection approfondie des charges utiles de votre application afin d'autoriser ou de refuser les requêtes, ou de modifier les requêtes ou les réponses, selon les besoins. Vous pouvez déléguer les décisions d'accès à Model Armor ou à votre propre extension de désinfection de contenu.

Une règle d'autorisation avec le profil de règle CONTENT_AUTHZ ne peut avoir qu'une action CUSTOM appliquée à la requête. Cela signifie que la demande ne peut pas être évaluée directement et doit être déléguée.

Une règle d'autorisation, configurée sur la règle de transfert de l'équilibreur de charge, pointe vers une extension d'autorisation de contenu. Pour chaque demande d'autorisation, l'équilibreur de charge transfère l'intégralité du contenu de la demande et de la réponse, y compris les en-têtes, le corps et les trailers, à l'aide du protocole ext_proc d'Envoy en mode de streaming duplex intégral (FULL_DUPLEX_STREAMED), à l'extension d'autorisation de contenu. En fonction de la réponse de l'extension, le proxy de l'équilibreur de charge transfère la requête à sa destination ou la refuse. La destination, dans le cas d'une requête, est le service de backend de l'équilibreur de charge, et dans le cas d'une réponse, c'est le client.

Déléguer les décisions d'autorisation

Les règles d'autorisation peuvent être évaluées directement ou être déléguées. Pour les décisions d'autorisation complexes qui ne peuvent pas être exprimées à l'aide d'une règle d'autorisation, vous pouvez créer une règle d'autorisation avec une action CUSTOM et déléguer la décision d'autorisation à un service géré par Google ou à un service géré par l'utilisateur via les Service Extensions.

• Service géré par Google
  • Model Armor
  • Identity-Aware Proxy
• Service géré par l'utilisateur
  • un service de backend Google Cloud
  • un service accessible par un nom de domaine complet (FQDN) compatible avec le protocole ext_proc ou ext_authz d'Envoy.

Le tableau suivant récapitule les différents services auxquels une décision d'autorisation peut être déléguée via les extensions de service.

Règle d'autorisation	Évalué directement	Délégué aux extensions de service (extension d'autorisation)
		Services gérés par Google		Services gérés par l'utilisateur
		Model Armor	Identity-Aware Proxy	Google Cloud service de backend	Service basé sur un nom de domaine complet
Profil REQUEST_AUTHZ
Profil CONTENT_AUTHZ

Extensions de service

Vous pouvez utiliser des règles d'autorisation pour déléguer les décisions d'autorisation aux extensions de service, en particulier celles de type "extension d'autorisation". Les extensions d'autorisation sont compatibles avec les appels pour injecter une logique personnalisée dans les équilibreurs de charge d'application Google Cloud. Cette fonctionnalité vous permet d'écrire votre propre code pour effectuer diverses activités sur le trafic traité par un équilibreur de charge, telles que la réécriture d'en-têtes, la sécurité incrémentielle, la journalisation personnalisée et l'authentification personnalisée des utilisateurs.

Avec les appels Service Extensions, vous demandez à l'équilibreur de charge de transférer le trafic à partir du chemin de traitement des données d'équilibrage de charge à l'aide d'appels gRPC vers un service d'appel, qui peut être géré par l'utilisateur ou par Google. Les différents services d'appel sont définis dans le tableau précédent. Ces services d'appel exécutent l'extension d'autorisation et peuvent appliquer diverses règles ou fonctions avant de renvoyer le trafic à l'équilibreur de charge pour un traitement ultérieur. Le schéma suivant illustre ce processus.

Règle d'autorisation déléguant la décision d'autorisation via une extension d'autorisation (cliquez pour agrandir)

Pour déléguer les décisions d'autorisation à une extension d'autorisation, créez une extension d'autorisation (AuthzExtension) qui s'exécute sur un service d'appel. Vous pouvez ensuite créer une règle d'autorisation avec une action CUSTOM et la pointer vers l'extension d'autorisation que vous avez créée. L'extension d'autorisation peut être utilisée pour effectuer à la fois une autorisation au niveau de la requête (REQUEST_AUTHZ) et une désinfection du contenu (CONTENT_AUTHZ).

Pour savoir comment déléguer la décision d'autorisation à un service de backendGoogle Cloud géré par l'utilisateur ou à un service basé sur un nom de domaine complet, consultez Déléguer la décision d'autorisation à un service géré par l'utilisateur.

Extensions d'autorisation dans le chemin de traitement des données

Lorsque vous déléguez une décision d'autorisation à des extensions de service, en particulier de type extension d'autorisation, notez la terminologie suivante :

• Lorsqu'une règle d'autorisation personnalisée avec un profil de règle REQUEST_AUTHZ pointe vers une extension d'autorisation (AuthzExtension), l'extension d'autorisation est appelée extension d'autorisation de requête.

• Lorsqu'une règle d'autorisation avec un profil de règle CONTENT_AUTHZ pointe vers une extension d'autorisation (AuthzExtension), l'extension d'autorisation est appelée extension d'autorisation de contenu.

Dans le chemin de traitement des requêtes, une extension d'autorisation des requêtes est d'abord appelée, suivie de l'évaluation des règles d'autorisation et de refus, puis de l'extension d'autorisation du contenu et enfin de l'extension de trafic. Une extension d'autorisation de contenu peut également être appelée dans le chemin de traitement des réponses. Le schéma suivant montre la séquence dans laquelle différentes extensions sont appelées.

Remarque : L'extension d'autorisation de requête n'est appelée que lorsque les en-têtes de requête arrivent. Le corps de la requête, ainsi que les en-têtes et le corps de la réponse, ne sont pas visibles par l'extension d'autorisation des requêtes.

Extension d'autorisation de requête appelée avant une extension d'autorisation de contenu (cliquez pour agrandir).

Vous pouvez considérer les différentes extensions comme des hooks qui se déclenchent à certains points du chemin de traitement des données. Pour en savoir plus sur les différentes extensions, consultez Points d'extensibilité dans le chemin de données d'équilibrage de charge dans la documentation Service Extensions.

Model Armor

Vous pouvez utiliser des règles d'autorisation pour permettre à Model Armor d'appliquer des consignes d'IA qui empêchent la génération de contenu nuisible, l'injection de prompt et la fuite de données.

Pour ce faire, vous pouvez créer une extension d'autorisation (AuthzExtension) qui s'exécute sur un service Model Armor. Vous pouvez ensuite créer une règle d'autorisation avec une action CUSTOM et un profil CONTENT_AUTHZ qui pointe vers l'extension d'autorisation que vous avez créée.

Pour savoir comment déléguer l'autorisation à Model Armor, consultez Déléguer la décision d'autorisation à Model Armor.

Identity-Aware Proxy

Vous pouvez déléguer les décisions d'autorisation à Identity-Aware Proxy. IAP vérifie l'identité de l'utilisateur et le contexte de la requête pour déterminer si cet utilisateur doit être autorisé à accéder à une application ou à une ressource.

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

Pour en savoir plus sur l'utilisation d'IAP en tant que service d'autorisation, consultez Déléguer la décision d'autorisation à Identity-Aware Proxy.

Règle d'autorisation basée sur les comptes principaux

Remarque : Les règles d'autorisation basées sur les principaux ne sont pas compatibles avec les équilibreurs de charge d'application externes globaux.

Pour identifier la source du trafic avec une grande précision, vous pouvez configurer des règles d'autorisation basées sur les identités dérivées du certificat d'un client. Cette méthode nécessite que le mTLS de l'interface soit activé sur l'équilibreur de charge. Elle utilise les attributs de certificat suivants comme sélecteur de principal pour l'identification :

• SAN des URI de certificat client (CLIENT_CERT_URI_SAN)
• SAN de nom DNS du certificat client (CLIENT_CERT_DNS_NAME_SAN)
• Nom commun du certificat client (CLIENT_CERT_COMMON_NAME)

Si aucun sélecteur de compte principal n'est spécifié pour l'identification, CLIENT_CERT_URI_SAN est utilisé comme sélecteur de compte principal par défaut. Cela signifie que les SAN URI du certificat client sont évalués lors de la prise de décisions d'autorisation.

Pour que l'autorisation basée sur les comptes principaux fonctionne, les conditions suivantes doivent être remplies :

• L'authentification mTLS de l'interface doit être activée. Si l'authentification mTLS du frontend n'est pas activée, le client ne présente pas de certificat. Par conséquent, les règles basées sur les comptes principaux de la stratégie d'autorisation ne trouvent aucune information sur les certificats à évaluer. Par exemple, une règle vérifiant CLIENT_CERT_URI_SAN voit une valeur vide.

• Un certificat client valide est requis. Même si l'authentification mTLS est activée, un certificat client n'est pas utilisé pour l'autorisation si la connexion a été établie avec un certificat manquant ou non valide. Ce scénario se produit lorsque le mode de validation du client mTLS est défini sur le mode permissif ALLOW_INVALID_OR_MISSING_CLIENT_CERT. Dans ce cas également, les règles basées sur les comptes principaux dans la règle d'autorisation ne trouvent aucune information sur les certificats à évaluer. Par exemple, une règle vérifiant CLIENT_CERT_URI_SAN voit une valeur vide.

Impact des limites de taille des attributs

Les décisions d'autorisation sont sensibles à la taille des attributs du certificat client. Une requête est refusée si un attribut dépasse sa limite de taille et que la règle est configurée pour valider cet attribut spécifique.

Un refus peut se produire dans les cas suivants :

• La règle est validée par rapport à CLIENT_CERT_URI_SAN, et les SAN URI du certificat dépassent la limite de taille.
• La règle est validée par rapport à CLIENT_CERT_DNS_NAME_SAN, et les SAN du nom DNS du certificat dépassent la limite de taille.
• La stratégie est validée par rapport à CLIENT_CERT_COMMON_NAME, et le sujet du certificat (qui contient le nom commun) dépasse la limite de taille.

Si l'attribut d'un certificat dépasse sa limite de taille, mais n'est pas explicitement validé par le sélecteur de principal de la règle, la requête est toujours évaluée par rapport aux règles de principal configurées. Par exemple, si une règle est configurée pour valider uniquement le CLIENT_CERT_DNS_NAME_SAN, une requête provenant d'un client avec des SAN d'URI surdimensionnés n'est pas refusée pour cette raison. La règle procède à l'évaluation de la requête en fonction de ses SAN de nom DNS.

Pour obtenir un exemple de règle d'autorisation basée sur des comptes principaux, consultez Règle d'autorisation pour refuser les requêtes.

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

Une stratégie d'autorisation basée sur des comptes de service ou des tags sécurisés est compatible avec les équilibreurs de charge suivants :

• Équilibreurs de charge d'application internes régionaux
• Équilibreurs de charge d'application internes interrégionaux

Remarque : L'application de règles d'autorisation basées sur des comptes de service ou des tags n'est pas compatible avec les équilibreurs de charge d'application externes.

Les règles d'autorisation basées sur des comptes de service et des tags sécurisés vous permettent d'appliquer des règles de sécurité en fonction de l'expéditeur du trafic (personne ou élément), plutôt que de la simple adresse IP. Cela entraîne un passage des règles basées sur les adresses IP aux contrôles basés sur l'identité, en utilisant des comptes de service et des tags sécurisés pour définir votre périmètre de sécurité. Par exemple, vous pouvez créer une règle d'autorisation pour effectuer les opérations suivantes :

• refuser à une VM Compute Engine avec un compte de service spécifique (my-sa-123@PROJECT_ID.iam.gserviceaccount.com) l'accès au chemin d'accès /api/payments.

• autoriser les VM Compute Engine avec un tag sécurisé (paire clé/valeur environment: prod) à accéder au chemin d'accès /api/payments.

Vous pouvez appliquer des règles d'autorisation basées sur des comptes de service ou des tags sécurisés associés à différents services Google Cloud . Tout trafic provenant de ces services Google Cloud , qui sont associés à un compte de service spécifique ou à un tag sécurisé, peut être autorisé, refusé ou délégué pour une évaluation plus approfondie.

Le tableau suivant répertorie les différents services Google Cloud qui acceptent l'utilisation de comptes de service et de tags sécurisés.

ServiceGoogle Cloud	Assistance pour les comptes de service	Compatibilité avec les tags sécurisés
Machine virtuelle (VM) Compute Engine
Nœud Google Kubernetes Engine (GKE)
Conteneur Google Kubernetes Engine (GKE)	^1	^1
VPC direct pour Cloud Run		^1
Connecteur d'accès au VPC sans serveur	^2	^2
Cloud VPN	^1	^1
Cloud Interconnect sur site	^1	^1
Équilibreur de charge d'application	^3	^3
Équilibreur de charge réseau	^3	^3

¹ Non compatible avec Google Cloud.

² L'adresse IP source est unique et peut être utilisée à la place.

³ Les comptes de service et les tags ne sont pas compatibles lorsque les équilibreurs de charge d'application et les équilibreurs de charge réseau servent de sources de trafic dans une architecture à plusieurs niveaux.

Le tableau suivant répertorie les différentes architectures de cloud privé virtuel (VPC) qui permettent d'utiliser des comptes de service et des tags.

VPC	Architecture VPC	Assistance
Dans le VPC	Plusieurs projets (VPC partagé)
Dans le VPC	Interrégional
VPC croisés	Lien d'appairage croisé (VPC de pair)
VPC croisés	Cross Private Service Connect
VPC croisés	Spokes Network Connectivity Center multiservices

Pour savoir comment configurer une règle d'autorisation basée sur des comptes de service et des tags associés à une ressource Google Cloud , consultez Règle d'autorisation basée sur des comptes de service ou des tags.

Quotas

Pour en savoir plus sur les quotas pour les règles d'autorisation, consultez Quotas et limites pour les règles d'autorisation.

Tarifs

Pour obtenir des informations sur les tarifs, consultez Tarifs du réseau : Cloud Load Balancing.

Étapes suivantes

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

• Configurer une extension d'autorisation