Présentation des règles d'autorisation

Une stratégie 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 limitées pour cette source. De plus, la stratégie d'autorisation décrit les conditions dans lesquelles une règle s'applique et spécifie une action à effectuer pour autoriser, refuser ou évaluer davantage le trafic.

Les règles d'autorisation vous permettent d'établir des vérifications de contrôle des accès pour le trafic entrant vers les équilibreurs de charge d'application. Les requêtes qui réussissent ces vérifications sont acheminées vers les services de backend. Les requêtes qui échouent à ces vérifications sont arrêtées avec une réponse non autorisée.

Les règles d'autorisation peuvent être configurées 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 stratégies d'autorisation sont appelées après l'évaluation des extensions de route, des stratégies de sécurité réseau (évaluées par Google Cloud Armor), des stratégies de partage de ressources entre origines (CORS) et des stratégies Identity-Aware Proxy (IAP), mais avant l'exécution des actions de gestion du trafic.

Pour en savoir plus sur le moment où les stratégies d'autorisation sont appelées dans le chemin de traitement des requêtes, consultez la section 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 la section Configurer la sécurité du service avec Envoy.

Règles des règles d'autorisation

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

Pour une stratégie 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é à passer par l'équilibreur de charge. Vous devez ajouter au moins une règle HTTP.

Pour une stratégie 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 autorisation. Un fournisseur personnalisé est requis, tandis que les règles HTTP sont facultatives.

Une correspondance de stratégie 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 stratégie.

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'une balise sécurisée.
  • to: spécifie les opérations autorisées par la règle, telles que les URL auxquelles il est possible d'accéder 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 stratégie 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. Si des règles ALLOW existent, mais qu'aucune correspondance n'est trouvée, 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 action ALLOW ne correspond à la requête. Dans Cloud Logging, cette action est enregistrée en tant que denied_as_no_allow_policies_matched_request.

    Pour qu'une action ALLOW soit 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 stratégie DENY. Si des règles DENY existent, mais qu'aucune correspondance n'est trouvée, 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 enregistrée en tant que 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'un IAP ou des extensions de service. Pour en savoir plus, consultez Utiliser des stratégies 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 stratégie 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 que la règle d'autorisation délègue la décision d'autorisation à un IAP:

    Créer la stratégie d'autorisation et activer l'IAP

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

Une stratégie 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 seule ressource, la règle CUSTOM est évaluée en premier, puis la règle DENY, et enfin la règle ALLOW. L'évaluation est déterminée par les règles suivantes:

  1. Si une règle CUSTOM correspond à la requête, la règle CUSTOM est évaluée à l'aide des fournisseurs d'autorisation personnalisés, et la requête est refusée si le fournisseur la rejette. Les règles DENY ou ALLOW ne sont pas évaluées, même si elles sont configurées.

  2. Si des règles DENY correspondent à 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 stratégie ALLOW n'existe, la requête est autorisée.

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

  5. Si des règles ALLOW existent, mais qu'aucune correspondance n'est trouvée, la requête est refusée. En d'autres termes, la requête est refusée par défaut si aucun des AuthzPolicies configurés avec l'action ALLOW ne correspond à la requête.

Délégation des décisions d'autorisation à l'aide de règles 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 que le proxy Identity-Aware (IAP), ou créez votre propre extension d'autorisation créée à 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 l'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é et le contexte de l'utilisateur 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 backend exposés depuis l'équilibreur de charge d'application. Pour en savoir plus, consultez la section Déléguer l'autorisation à l'IAP et à IAM.

    Vous pouvez choisir de déléguer l'authentification à l'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é exécuté sur des instances de VM Google Cloud ou sur site. Cela offre une 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 des comptes de service ou des tags

Vous pouvez utiliser des attributs tels que des comptes de service ou des 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 en fonction 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écifique peut être autorisé, refusé ou délégué à un service externe.

Les tableaux suivants répertorient les ressources sources et les différentes architectures de cloud privé virtuel (VPC) compatibles avec l'utilisation de comptes de service et de tags.

Source Assistance pour les comptes de service Compatibilité avec 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 VPC Assistance
Dans le VPC Inter-projet (VPC partagé)
Dans le VPC Interrégional
VPC croisé Lien d'appairage croisé (VPC de pair)
VPC croisé Private Service Connect croisé
VPC croisé Interconnexion des spokes Network Connectivity Center

Pour en savoir plus sur la configuration d'une règle d'autorisation basée sur des comptes de service et des balises associées à une ressource de VM Google Cloud , consultez la section Règle d'autorisation basée sur des comptes de service ou des balises.

Quotas

Pour en savoir plus sur les quotas des stratégies d'autorisation, consultez la section Quotas et limites des stratégies d'autorisation.

Tarifs

Les règles d'autorisation ne sont pas facturées pendant la période de preview. Cependant, des frais de mise en réseau vous sont facturés lorsque vous utilisez des Google Cloud équilibreurs de charge. Pour en savoir plus sur la tarification, consultez la section Tarifs.

Étape suivante