Une règle d'autorisation (AuthzPolicy) appliquée à la règle de transfert des équilibreurs de charge d'application définit des règles spécifiant la source du trafic entrant et les opérations autorisées ou restreintes pour cette source.
De plus, la règle d'autorisation décrit les conditions dans lesquelles une règle s'applique et spécifie une action pour autoriser, refuser ou évaluer plus en détail le trafic.
Les règles d'autorisation vous permettent d'établir des vérifications du contrôle d'accès pour le trafic entrant vers les équilibreurs de charge d'application. Les requêtes qui passent ces vérifications sont acheminées vers les services de backend. Les requêtes qui échouent à ces vérifications sont interrompues et une réponse non autorisée est renvoyé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
Dans les équilibreurs de charge d'application, les règles d'autorisation sont appelées après l'évaluation des extensions de route, des règles de sécurité réseau (évaluées par Google Cloud Armor), des règles de partage des ressources d'origine croisée (CORS) et des règles Identity-Aware Proxy (IAP), mais avant l'exécution des actions de gestion du trafic.
Pour savoir quand les règles d'autorisation sont appelées dans le chemin de traitement des requêtes, consultez Points d'extensibilité dans le chemin de données d'équilibrage de charge.
Si vous souhaitez utiliser des règles d'autorisation pour les services déployés avec Cloud Service Mesh, consultez Configurer la sécurité des services avec Envoy.
Règles des règles d'autorisation
Une règle d'autorisation se compose d'une liste de règles HTTP à comparer à 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 définir 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: autorise la requête à passer au backend si elle correspond à l'une des règles spécifiées dans une règleALLOW. S'il existe des règlesALLOW, mais qu'aucune ne correspond, la requête est refusée. En d'autres termes, la requête est refusée si aucune des stratégies d'autorisation configurées avec une actionALLOWne correspond à la requête. Dans Cloud Logging, cette action est consignée sous la formedenied_as_no_allow_policies_matched_request.Pour qu'une action
ALLOWsoit appliquée, vous devez disposer d'au moins une règle HTTP.DENY: refuse la requête si elle correspond à l'une des règles spécifiées dans une règleDENY. Si des règlesDENYexistent, 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 actionDENYne correspond à la requête. Dans Cloud Logging, cette action est consignée sous la formeallowed_as_no_deny_policies_matched_request.Pour qu'une action
DENYsoit 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 Utiliser des règles d'autorisation pour 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 l'exemple suivant dans lequel aucune règle HTTP n'est définie et la règle d'autorisation délègue la décision d'autorisation à un IAP :
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 :
S'il existe une règle
CUSTOMqui correspond à la requête, elle est évaluée à l'aide des fournisseurs d'autorisation personnalisés. La requête est refusée si le fournisseur la rejette.CUSTOMLes règlesDENYouALLOWne sont pas évaluées, même si certaines sont configurées.S'il existe des règles
DENYqui correspondent à la requête, celle-ci est refusée. Les règlesALLOWne sont pas évaluées, même si elles sont configurées.Si aucune règle
ALLOWn'existe, la requête est autorisée.Si l'une des règles
ALLOWcorrespond à la requête, autorisez-la.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 desAuthzPoliciesconfigurées avec l'actionALLOWne correspond à la requête.
Utiliser des règles d'autorisation pour déléguer les décisions d'autorisation
Pour les décisions d'autorisation complexes qui ne peuvent pas être exprimées à l'aide de la règle d'autorisation, déléguez la décision d'autorisation à des fournisseurs d'autorisation personnalisés, tels qu'Identity-Aware Proxy (IAP), ou créez votre propre extension d'autorisation à l'aide des extensions de service. Cela est utile lorsque vous souhaitez utiliser votre moteur d'autorisation sur site ou des fournisseurs d'identité tiers via IAP.
IAP : configurez IAP pour contrôler l'accès aux applications derrière les règles de transfert de l'équilibreur de charge d'application. IAP vérifie l'identité de l'utilisateur et le contexte pour déterminer l'accès. Il peut également authentifier les jetons de compte de service IAM (Identity and Access Management) et évaluer les stratégies IAM, ce qui protège l'accès aux buckets de backend exposés par l'équilibreur de charge d'application. Pour en savoir plus, consultez Déléguer l'autorisation à IAP et IAM.
Vous pouvez choisir de déléguer l'authentification à IAP et IAM dans les cas suivants :
- Utilisez IAM pour gérer les autorisations.
- Implémentez l'accès contextuel.
- Utilisez l'authentification basée sur le navigateur pour les applications Web qui nécessitent une authentification interactive.
Extensions de service : déléguez les décisions d'autorisation à votre moteur d'autorisation personnalisé s'exécutant sur des instances de VM Google Cloud ou sur site. Cela offre de la flexibilité pour les règles d'autorisation complexes qui ne sont pas couvertes par les règles intégrées. Pour en savoir plus, consultez Configurer une extension d'autorisation.
Règle d'autorisation basée sur les comptes principaux
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 dans la règle d'autorisation ne trouvent aucune information de certificat à évaluer. Par exemple, une règle vérifiant
CLIENT_CERT_URI_SANvoit une valeur vide.Un certificat client valide doit être disponible. 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 de la règle d'autorisation ne trouvent aucune information sur les certificats à évaluer. Par exemple, une règle vérifiantCLIENT_CERT_URI_SANvoit 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 d'un client avec des SAN d'URI surdimensionnés n'est pas rejetée pour cette raison. La règle procède à l'évaluation de la requête en fonction de ses SAN de nom DNS.
Règle d'autorisation basée sur des comptes de service ou des tags
Vous pouvez utiliser des attributs tels que les comptes de service ou les tags pour identifier la source du trafic des équilibreurs de charge d'application internes.
Pour les équilibreurs de charge d'application internes, vous pouvez appliquer des règles d'autorisation basées sur des comptes de service ou des tags associés aux ressources Google Cloud . Tout trafic provenant de ces ressources Google Cloud associées à un compte de service ou à une balise spécifiques peut être autorisé, refusé ou délégué à un service externe.
Les tableaux suivants listent les ressources sources et les différentes architectures de cloud privé virtuel (VPC) qui permettent d'utiliser des comptes de service et des tags.
| Source | Assistance pour les comptes de service | Assistance pour les balises |
|---|---|---|
| VM | ||
| Nœud GKE | ||
| Conteneur GKE | * | * |
| VPC direct pour Cloud Run | * | |
| Connecteur d'accès au VPC sans serveur | † | † |
| Cloud VPN | * | * |
| Cloud Interconnect sur site | * | * |
| Équilibreur de charge d'application | ||
| Équilibreur de charge réseau |
* Non compatible avec Google Cloud.
† L'adresse IP source est unique et peut être utilisée à la place.
| VPC | Architecture du VPC | Assistance |
|---|---|---|
| Dans le VPC | Plusieurs projets (VPC partagé) | |
| Dans le VPC | Interrégional | |
| Cross-VPC | Lien d'appairage croisé (VPC de pair) | |
| Cross-VPC | Cross Private Service Connect | |
| Cross-VPC | 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 de VM 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
Les règles d'autorisation ne sont pas facturées pendant la période de la version Preview. Toutefois, des frais de mise en réseau vous sont facturés lorsque vous utilisez des équilibreurs de charge Google Cloud . Pour en savoir plus sur la tarification, consultez la page Tarifs.