Exposer des applications Azure Spring Apps par le biais d’un proxy inverse

Azure Spring Apps
Azure Application Gateway
Azure Front Door

Quand vous hébergez vos applications ou microservices dans Azure Spring Apps, vous pouvez décider de ne pas les publier directement sur Internet. Vous pouvez à la place les exposer par le biais d’un proxy inverse. Cette approche vous permet de placer un service devant vos applications. Le service peut définir des fonctionnalités transversales comme le pare-feu d'application web (WAF) pour la sécurisation de vos applications, l'équilibrage de charge, le routage, le filtrage des requêtes et la limitation du débit.

Quand vous déployez un service de proxy inverse commun comme Azure Application Gateway ou Azure Front Door devant Azure Spring Apps, vous devez vérifier que vos applications peuvent uniquement être atteintes par le biais du proxy inverse. Cette protection permet d'empêcher les utilisateurs malveillants de contourner le pare-feu d'applications web (WAF) ou les limitations.

Azure DDoS Protection, combiné aux bonnes pratiques de conception d’application, offre des fonctionnalités d’atténuation des attaques DDoS améliorées pour une meilleure défense contre les attaques DDoS. Vous devez activer Azure DDOS Protection sur tout réseau virtuel de périmètre.

Cet article décrit comment appliquer des restrictions d'accès pour que les applications hébergées dans Azure Spring Apps soient uniquement accessibles par le biais d'un service de proxy inverse. La méthode recommandée pour appliquer ces restrictions dépend de la façon dont vous déployez votre instance Azure Spring Apps et du proxy inverse que vous utilisez. Il y a différents points à prendre en compte selon que le déploiement se fait à l'intérieur ou à l'extérieur d'un réseau virtuel. Cet article fournit des informations sur quatre scénarios.

  • Déployez Azure Spring Apps dans un réseau virtuel et accédez à vos applications en privé à partir du réseau.

    • Vous contrôlez le réseau virtuel dans lequel vos applications s'exécutent. Utilisez les fonctionnalités réseau natives d'Azure comme les groupes de sécurité réseau (NSG) pour verrouiller l'accès afin d'autoriser uniquement votre proxy inverse.

    • Vous pouvez exposer vos applications publiquement sur Internet en utilisant Azure Application Gateway, puis appliquer les restrictions appropriées pour verrouiller l'accès. Cette approche est décrite dans le scénario 1 plus loin dans cet article.

    • Vous ne pouvez pas utiliser Azure Front Door directement, car il ne peut pas atteindre l'instance Azure Spring Apps dans votre réseau virtuel privé. Azure Front Door peut se connecter aux back-ends uniquement par le biais d'une adresse IP publique ou de services qui utilisent un point de terminaison privé. Lorsque vous disposez d'un déploiement multirégion d'Azure Spring Apps et que vous avez besoin d'un équilibrage de charge global, vous pouvez toujours exposer vos instances Azure Spring Apps via Application Gateway. Pour réaliser ce scénario, vous placez Azure Front Door devant Application Gateway. Cette approche est décrite dans le scénario 2 plus loin dans cet article.

  • Déployez Azure Spring Apps en dehors d'un réseau virtuel et publiez vos applications directement sur Internet si vous leur affectez un point de terminaison.

    • Vous ne contrôlez pas le réseau et ne pouvez pas utiliser de NSG pour en restreindre l'accès. Le fait d'autoriser uniquement le proxy inverse à accéder à vos applications nécessite une approche au sein même d'Azure Spring Apps.

    • Comme vos applications sont accessibles au public, vous pouvez utiliser Application Gateway ou Azure Front Door comme proxy inverse. L'approche Application Gateway est décrite dans le scénario 3 plus loin dans cet article. L'approche Azure Front Door est décrite dans le scénario 4 plus loin dans cet article.

    • Vous pouvez utiliser une combinaison des deux approches, si nécessaire. Si vous utilisez à la fois Application Gateway et Azure Front Door, utilisez les mêmes restrictions d'accès entre les deux proxys inverses que dans le scénario 2.

Notes

Vous pouvez utiliser des services de proxy inverse autres qu’Application Gateway ou Azure Front Door. Pour des services régionaux basés sur un réseau virtuel Azure, comme Gestion des API Azure, les instructions sont similaires à celles fournies pour Application Gateway. Si vous utilisez des services non-Azure, les instructions sont similaires à celles fournies pour Azure Front Door.

Comparaison de scénarios

Le tableau suivant fournit une brève comparaison des quatre scénarios de configuration de proxy inverse pour Azure Spring Apps. Pour plus d’informations sur chaque scénario, reportez-vous à la section appropriée de cet article.

Scénario Déploiement Services Configuration
1 À l'intérieur du réseau virtuel Application Gateway – Pour chaque application que vous souhaitez exposer, attribuez-lui un point de terminaison et mappez le ou les domaines personnalisés appropriés à cette application.
– Pour le pool de back-ends dans Application Gateway, utilisez le point de terminaison attribué de chaque application.
– Dans le sous-réseau d'exécution du service, ajoutez un groupe de sécurité réseau pour autoriser uniquement le trafic provenant du sous-réseau Application Gateway, du sous-réseau des applications et de l'équilibreur de charge Azure. Bloquez tout autre trafic.
2 À l'intérieur du réseau virtuel Azure Front Door et Application Gateway – Limitez l'accès entre Application Gateway et Azure Spring Apps à l'aide de la même approche que celle décrite pour le scénario 1.
– Sur le sous-réseau Application Gateway, créez un NSG pour autoriser uniquement le trafic associé à l'étiquette de service AzureFrontDoor.Backend.
– Créez une règle WAF personnalisée dans Application Gateway pour vérifier que l'en-tête HTTP de X-Azure-FDID contient votre ID d'instance Azure Front Door spécifique.
3 En dehors du réseau virtuel Application Gateway avec Spring Cloud Gateway – Utilisez Spring Cloud Gateway pour exposer vos applications back-end. Seule l'application Spring Cloud Gateway nécessite un point de terminaison attribué. Les domaines personnalisés de toutes les applications back-end doivent être mappés à cette seule application Spring Cloud Gateway.
– Pour le pool de back-ends dans Application Gateway, utilisez le point de terminaison attribué de l'application Spring Cloud Gateway.
– Dans Spring Cloud Gateway, définissez le prédicat de route XForwarded Remote Addr avec l'adresse IP publique d'Application Gateway.
– Si vous le souhaitez, dans vos applications Spring Framework, définissez la propriété d'application server.forward-headers-strategy avec la valeur FRAMEWORK.
4 En dehors du réseau virtuel Azure Front Door avec Spring Cloud Gateway – Utilisez Spring Cloud Gateway pour exposer vos applications back-end. Seule l'application Spring Cloud Gateway nécessite un point de terminaison attribué. Les domaines personnalisés de toutes les applications back-end doivent être mappés à cette seule application Spring Cloud Gateway.
– Pour l'origine ou le pool de back-ends dans Azure Front Door, utilisez le point de terminaison attribué de l'application Spring Cloud Gateway.
– Dans Spring Cloud Gateway, définissez le prédicat de route XForwarded Remote Addr avec toutes les plages d'adresses IP sortantes d'Azure Front Door et maintenez ce paramètre à jour. Définissez le prédicat de route Header pour faire en sorte que l’en-tête HTTP X-Azure-FDID contienne votre ID Azure Front Door unique.
– Si vous le souhaitez, dans vos applications Spring Framework, définissez la propriété d'application server.forward-headers-strategy avec la valeur FRAMEWORK.

Notes

Une fois votre configuration en place, envisagez d'utiliser Azure Policy ou des verrous de ressources pour empêcher toute modification accidentelle ou malveillante susceptible de contourner le proxy inverse et d'exposer directement l'application. Cette protection s’applique uniquement aux ressources Azure (plus précisément, aux NSG), car la configuration au sein des applications Azure Spring Apps n’est pas visible dans le plan de contrôle Azure.

Déploiement à l'intérieur de votre réseau virtuel

Quand Azure Spring Apps est déployé dans un réseau virtuel, il utilise deux sous-réseaux :

  • Un sous-réseau d'exécution du service qui contient les ressources réseau appropriées
  • Un sous-réseau d'applications qui héberge votre code

Dans la mesure où le sous-réseau d'exécution du service contient l'équilibreur de charge pour la connexion de vos applications, vous pouvez définir un NSG sur ce sous-réseau de runtime du service pour autoriser uniquement le trafic provenant de votre proxy inverse. Quand vous bloquez tous les autres trafics, toute personne dans le réseau virtuel doit passer par le proxy inverse pour accéder à vos applications.

Important

Le fait de restreindre l'accès au sous-réseau au proxy inverse peut causer la défaillance des fonctionnalités qui dépendent d'une connexion directe entre un appareil client et l'application, comme le streaming de journaux. Envisagez d'ajouter des règles NSG spécifiquement pour ces appareils clients, uniquement lorsqu'un accès direct spécifique est requis.

Chaque application que vous souhaitez exposer par le biais de votre proxy inverse doit avoir un point de terminaison attribué afin que le proxy inverse puisse atteindre l'application dans le réseau virtuel. Pour chaque application, vous devez également mapper les domaines personnalisés qu'elle utilise pour éviter de remplacer l'en-tête HTTP Host dans le proxy inverse et conserver le nom d'hôte d'origine. Cette méthode permet d'éviter des problèmes tels que des cookies endommagés ou des URL de redirection dysfonctionnelles. Pour plus d’informations, consultez Conservation du nom d’hôte.

Notes

En guise d'alternative (ou, pour une défense en profondeur, en plus du NSG), vous pouvez suivre les instructions relatives à Azure Spring Apps déployés en dehors de votre réseau virtuel. Cette section explique comment les restrictions d'accès sont généralement mises en place avec Spring Cloud Gateway (ce qui affecte également les applications back-end, car elles n'ont plus besoin d'un domaine personnalisé ou d'un point de terminaison attribué).

Scénario 1 : utiliser Application Gateway comme proxy inverse

Le scénario 1 décrit comment exposer vos applications publiquement sur Internet en utilisant Application Gateway, puis appliquer les restrictions appropriées pour verrouiller l'accès.

Le schéma ci-dessous illustre l'architecture du scénario 1 :

Diagram that shows the use of Azure Application Gateway with Azure Spring Apps in a virtual network.

Téléchargez un fichier Visio de cette architecture.

Quand Application Gateway se trouve devant votre instance Azure Spring Apps, vous utilisez le point de terminaison attribué de l’application Spring Cloud Gateway comme pool de back-ends. Voici un exemple de point de terminaison myspringcloudservice-myapp.private.azuremicroservices.io. Le point de terminaison correspond à une adresse IP privée dans le sous-réseau de runtime du service. Pour restreindre l’accès, vous pouvez donc placer un NSG sur le sous-réseau d’exécution du service avec les règles de sécurité entrantes suivantes (en attribuant à la règle Deny la priorité la plus basse) :

Action Type de source Valeur source Protocol Plages de ports de destination
Autoriser Adresses IP Plage d'adresses IP privées du sous-réseau Application Gateway (par exemple, 10.1.2.0/24) TCP 80, 443 (ou d’autres ports selon le cas)
Autoriser Adresses IP Plage d'adresses IP privées du sous-réseau d'applications dans Azure Spring Apps (par exemple, 10.1.1.0/24) TCP *
Autoriser Balise du service AzureLoadBalancer Any *
Deny Balise du service Any Any *

La configuration du scénario 1 garantit que le sous-réseau d'exécution du service n'autorise que le trafic provenant des sources suivantes :

  • Le sous-réseau Application Gateway dédié.
  • Le sous-réseau des applications (une communication bidirectionnelle entre les deux sous-réseaux Azure Spring Apps est nécessaire.)
  • L'équilibreur de charge Azure (exigence générale de la plateforme Azure).

Tous les autres trafics sont bloqués.

Scénario 2 : utiliser à la fois Azure Front Door et Application Gateway comme proxy inverse

Comme indiqué précédemment, vous ne pouvez pas placer Azure Front Door directement devant Azure Spring Apps, car il ne peut pas atteindre votre réseau virtuel privé. (Azure Front Door Standard ou Premium peut se connecter à des points de terminaison privés dans un réseau virtuel, mais Azure Spring Apps ne prend actuellement pas en charge les points de terminaison privés.) Pour utiliser tout de même Azure Front Door, par exemple si vous avez besoin d'un équilibrage de charge global sur plusieurs instances d'Azure Spring Apps dans différentes régions Azure, vous pouvez toujours exposer vos applications via Application Gateway. Pour réaliser ce scénario, vous placez Azure Front Door devant Application Gateway.

Le schéma ci-dessous illustre l'architecture du scénario 2 :

Diagram that shows the use of Azure Front Door and Azure Application Gateway with Azure Spring Apps in a virtual network.

Téléchargez un fichier Visio de cette architecture.

La configuration du scénario 2 implémente des restrictions d'accès entre Application Gateway et Azure Spring Apps de la même manière que le scénario 1. Vous placez un NSG sur le sous-réseau d'exécution du service avec les règles appropriées.

Dans le scénario 2, vous devez également vérifier qu'Application Gateway accepte uniquement le trafic provenant de votre instance Azure Front Door. La documentation Azure Front Door explique comment verrouiller l'accès à un back-end pour autoriser uniquement le trafic Azure Front Door. Quand le back-end est Application Gateway, vous pouvez implémenter cette restriction comme ceci :

Déploiement en dehors de votre réseau virtuel

Quand vous déployez Azure Spring Apps en dehors d’un réseau virtuel, vous ne pouvez pas utiliser les fonctionnalités réseau natives d’Azure puisque vous ne contrôlez pas le réseau. Au lieu de cela, vous devez appliquer les restrictions d'accès nécessaires sur les applications elles-mêmes afin qu'elles autorisent uniquement le trafic provenant du proxy inverse. Si vous avez de nombreuses applications, cette approche peut compliquer les choses. Il y a aussi le risque que toutes les applications ne soient pas configurées correctement.

Utiliser Spring Cloud Gateway pour exposer et sécuriser vos applications

Pour retirer la responsabilité de contrôle d'accès aux développeurs d'applications individuelles, vous pouvez appliquer des restrictions transversales avec Spring Cloud Gateway. Spring Cloud Gateway est un projet Spring couramment utilisé que vous pouvez déployer dans Azure Spring Apps comme n’importe quelle autre application. En utilisant Spring Cloud Gateway, vous pouvez garder vos propres applications privées dans l'instance Azure Spring Apps et vous assurer qu'elles ne sont accessibles que par le biais de l'application Spring Cloud Gateway partagée. Vous configurez ensuite cette application avec les restrictions d'accès nécessaires au moyen de prédicats de route (fonctionnalité intégrée à Spring Cloud Gateway). Les prédicats de route peuvent utiliser différents attributs de la requête HTTP entrante pour déterminer s'il faut router la requête vers l'application back-end ou la rejeter. Le prédicat peut utiliser des attributs tels que l'adresse IP du client, la méthode ou le chemin de requête, les en-têtes HTTP, etc.

Important

Quand vous placez Spring Cloud Gateway devant vos applications back-end de cette manière, vous devez mapper tous vos domaines personnalisés à l'application Spring Cloud Gateway plutôt qu'aux applications back-end. Sinon, Azure Spring Apps ne route pas d’abord le trafic entrant vers votre passerelle Cloud Spring Gateway quand une demande arrive pour l’un de ces domaines personnalisés.

Cette approche suppose que votre proxy inverse ne remplace pas l'en-tête HTTP Host et conserve le nom d'hôte d'origine. Pour plus d’informations, consultez Conservation du nom d’hôte.

Ce modèle est couramment utilisé. Pour les besoins de cet article, nous partons du principe que vous exposez vos applications via Spring Cloud Gateway. Nous partons du principe que vous utilisez ses prédicats de route pour configurer les restrictions d'accès nécessaires afin de garantir que seules les requêtes du proxy inverse sont autorisées. Même si vous n’utilisez pas Spring Cloud Gateway, les mêmes principes généraux s’appliquent. Toutefois, vous devez créer vos propres fonctionnalités de filtrage de demandes dans vos applications, en fonction du même en-tête HTTP X-Forwarded-For abordé plus loin dans cet article.

Notes

Spring Cloud Gateway est également un proxy inverse qui fournit des services tels que le routage, le filtrage des demandes et la limitation du débit. Si ce service vous apporte toutes les fonctionnalités dont vous avez besoin pour votre scénario, vous n'aurez peut-être pas besoin d'un proxy inverse supplémentaire comme Application Gateway ou Azure Front Door. Les autres services Azure peuvent toutefois être utiles pour deux raisons principales : les fonctionnalités WAF qu'ils offrent tous les deux et les capacités d'équilibrage de charge global d'Azure Front Door.

Le fonctionnement de Spring Cloud Gateway n’est pas traité dans cet article. C’est un service très flexible que vous pouvez personnaliser avec du code ou une configuration. Pour simplifier les choses, cet article décrit uniquement une approche purement basée sur la configuration qui ne nécessite aucune modification du code. Vous pouvez implémenter cette approche en incluant le fichier traditionnel application.properties ou application.yml dans l’application Spring Cloud Gateway déployée. Vous pouvez également implémenter l'approche en utilisant un Config Server dans Azure Spring Apps, qui externalise le fichier de configuration dans un référentiel Git. Dans les exemples suivants, nous implémentons l'approche application.yml avec la syntaxe YAML, mais la syntaxe équivalente application.properties fonctionne également.

Routage des demandes vers vos applications

Par défaut, si aucun point de terminaison n’est attribué à votre application ou si aucun domaine personnalisé n’est configuré pour votre application dans Azure Spring Apps, l’application ne peut pas être atteinte de l’extérieur. Quand une application s'inscrit auprès de Spring Cloud Service Registry, Spring Cloud Gateway peut découvrir l'application et utiliser des règles de routage pour transférer le trafic vers l'application de destination appropriée.

Par conséquent, la seule application à laquelle un point de terminaison doit être attribué dans Azure Spring Apps est votre application Spring Cloud Gateway. Grâce à ce point de terminaison, elle peut être atteinte de l’extérieur. N'attribuez pas de point de terminaison aux autres applications. Sinon, les applications peuvent être atteintes directement sans passer par Spring Cloud Gateway, ce qui peut déboucher sur le contournement du proxy inverse.

Un moyen simple d'exposer toutes les applications inscrites par le biais de Spring Cloud Gateway consiste à utiliser le localisateur de définition de route DiscoveryClient, comme ceci :

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true
          predicates:
          - Path="/"+serviceId+"/**" # Include the Path predicate to retain default behavior
          - (...)

Vous pouvez également exposer de manière sélective certaines applications par le biais de Spring Cloud Gateway en définissant des routes spécifiques aux applications :

spring:
  cloud:
    gateway:
      routes:
      - id: my_app1_route
        uri: lb://MY-APP1
        filters:
        - RewritePath=/myapp1(?<segment>/?.*), $\{segment}
        predicates:
        - (...)

Grâce au localisateur de découverte et aux définitions de routes explicites, vous pouvez utiliser des prédicats de route pour rejeter les demandes non valides. Dans ce cas, nous utilisons cette fonctionnalité pour bloquer les demandes qui ne proviennent pas du proxy inverse attendu qui se trouve devant Azure Spring Apps.

Restreindre l'accès avec l'en-tête HTTP X-Forwarded-For

Quand vous déployez une application dans Azure Spring Apps, le client HTTP ou le proxy inverse ne se connecte pas directement à l'application. Le trafic réseau passe d’abord par un contrôleur d’entrée interne.

Notes

Cette approche signifie que vous avez trois ou même quatre proxys inverses dans le pipeline de demandes avant d'atteindre votre application dans les scénarios qui suivent. Voici les proxys inverses possibles : Azure Front Door et/ou Application Gateway, le contrôleur d’entrée et votre application Spring Cloud Gateway.

En raison du service supplémentaire, l'adresse IP du client réseau direct est toujours un composant Azure Spring Apps interne. L'adresse IP n'est jamais le client logique, comme le proxy inverse, que vous attendez pour appeler votre application. Vous ne pouvez pas utiliser l'adresse IP du client pour les restrictions d'accès. Vous ne pouvez également pas utiliser le prédicat de route RemoteAddr intégré de Spring Cloud Gateway pour le filtrage des demandes, car il utilise l'adresse IP du client par défaut.

Heureusement, Azure Spring Apps ajoute toujours l’adresse IP du client logique à l’en-tête HTTP X-Forwarded-For de la demande dans votre application. La dernière valeur (la plus à droite) de l'en-tête X-Forwarded-For contient toujours l'adresse IP du client logique.

Pour filtrer les requêtes en fonction de l'en-tête X-Forwarded-For, vous pouvez utiliser le prédicat de route XForwarded Remote Addr intégré. Celui-ci vous permet de configurer une liste des adresses IP ou des plages d'adresses IP de votre proxy inverse qui sont autorisées comme valeur la plus à droite.

Notes

Le prédicat de route XForwarded Remote Addr nécessite la version 3.1.1 ou ultérieure de Spring Cloud Gateway. La version 3.1.1 est disponible dans la version Spring Cloud 2021.0.1. Si vous ne pouvez pas utiliser cette version, vous pouvez également apporter quelques modifications de code à votre application Spring Cloud Gateway pour modifier la façon dont le prédicat de route RemoteAddr détermine l'adresse IP du client. Vous pouvez obtenir le même résultat qu'avec le prédicat de route XForwarded Remote Addr. Configurez le prédicat de route RemoteAddr pour utiliser XForwardedRemoteAddressResolver et configurer ce dernier avec une valeur maxTrustedIndex de 1. Cette approche configure votre application Spring Cloud Gateway pour utiliser la valeur la plus à droite de l'en-tête X-Forwarded-For comme adresse IP du client logique.

Configurer votre application pour voir le bon nom d'hôte et la bonne URL de demande

Lorsque vous utilisez Spring Cloud Gateway, il existe un facteur important à prendre en compte. Spring Cloud Gateway définit l'en-tête HTTP Host de la demande sortante avec l'adresse IP interne de votre instance d'application, comme Host: 10.2.1.15:1025. Le nom d'hôte de la demande que voit le code de votre application n'est plus le nom d'hôte d'origine de la demande envoyée par le navigateur, comme contoso.com. Dans certains cas, ce résultat peut entraîner des problèmes comme des cookies endommagés ou des URL de redirection dysfonctionnelles. Pour plus d’informations sur ces types de problèmes et sur la façon de configurer un service de proxy inverse comme Application Gateway ou Azure Front Door pour les éviter, consultez Conservation du nom d’hôte.

Spring Cloud Gateway fournit le nom d'hôte d'origine dans l'en-tête Forwarded. Il définit également d'autres en-têtes tels que X-Forwarded-Port, X-Forwarded-Proto et X-Forwarded-Prefix. Votre application peut donc les utiliser pour reconstruire l'URL de requête d'origine. Dans les applications Spring Framework, vous pouvez parvenir à cette configuration automatiquement en définissant le paramètre server.forward-headers-strategy sur FRAMEWORK dans les propriétés de votre application. (Ne définissez pas cette valeur sur NATIVE. Sinon, d'autres en-têtes sont utilisés sans tenir compte de l'en-tête X-Forwarded-Prefix.) Pour plus d'informations, reportez-vous à Exécution derrière un serveur proxy front-end. Avec cette configuration, la méthode HttpServletRequest.getRequestURL prend en compte tous ces en-têtes et retourne l'URL de demande telle qu'elle est envoyée par le navigateur.

Notes

Vous pouvez être tenté d’utiliser le filtre PreserveHostHeader dans Spring Cloud Gateway, qui conserve le nom d’hôte d’origine sur la demande sortante. Toutefois, cette approche ne fonctionne pas dans la mesure où ce nom d’hôte est déjà mappé en tant que domaine personnalisé sur l’application Spring Cloud Gateway. Il ne peut pas être mappé une deuxième fois sur l’application back-end finale. Cette configuration génère une erreur HTTP 404, car l’application back-end rejette la demande entrante. Elle ne reconnaît pas le nom d’hôte.

Scénario 3 : utiliser Application Gateway avec Spring Cloud Gateway

Le scénario 3 décrit comment utiliser Application Gateway comme proxy inverse pour les applications accessibles au public via un point de terminaison Spring Cloud Gateway.

Le schéma ci-dessous illustre l'architecture du scénario 3 :

Diagram that shows the use of Azure Application Gateway with Azure Spring Apps outside of a virtual network.

Téléchargez un fichier Visio de cette architecture.

Quand Application Gateway se trouve devant votre instance Azure Spring Apps, vous utilisez le point de terminaison attribué de l’application Spring Cloud Gateway comme pool de back-ends. Voici un exemple de point de terminaison myspringcloudservice-mygateway.azuremicroservices.io. Azure Spring Apps étant déployé en dehors d’un réseau virtuel, cette URL correspond à une adresse IP publique. Quand le pool de back-ends est un point de terminaison public, Application Gateway utilise son adresse IP publique front-end pour atteindre le service back-end.

Pour autoriser uniquement les requêtes de votre instance Application Gateway à atteindre Spring Cloud Gateway, vous pouvez configurer le prédicat de route XForwarded Remote Addr. Configurez le prédicat pour autoriser uniquement les requêtes provenant de l'adresse IP publique dédiée de votre Application Gateway, comme illustré dans l'exemple suivant :

(...)
predicates:
- XForwardedRemoteAddr="20.103.252.85"

Scénario 4 : utiliser Azure Front Door avec Spring Cloud Gateway

Le scénario 4 décrit comment utiliser Azure Front Door comme proxy inverse pour les applications accessibles au public via un point de terminaison Spring Cloud Gateway.

Le schéma ci-dessous illustre l'architecture du scénario 4 :

Diagram that shows the use of Azure Front Door with Azure Spring Apps outside of a virtual network.

Téléchargez un fichier Visio de cette architecture.

À l'instar du scénario 3, cette configuration utilise l'URL publique de l'application Spring Cloud Gateway comme pool ou origine de back-ends dans Azure Front Door. Voici un exemple de point de terminaison https://myspringcloudservice-mygateway.azuremicroservices.io.

Azure Front Door étant un service mondial doté de nombreux emplacements de périphérie, il utilise de nombreuses adresses IP pour communiquer avec son pool de back-ends. La documentation Azure Front Door décrit comment verrouiller l'accès à un back-end pour autoriser uniquement le trafic Azure Front Door. Toutefois, dans ce scénario, vous ne contrôlez pas le réseau Azure dans lequel vos applications sont déployées. Malheureusement, vous ne pouvez pas utiliser l'étiquette de service AzureFrontDoor.Backend pour obtenir une liste complète et garantie à jour des adresses IP Azure Front Door sortantes. Au lieu de cela, vous devez télécharger le fichier Plages d'adresse IP Azure et étiquettes de service, rechercher la section AzureFrontDoor.Backend et copier toutes les plages d'adresses IP du tableau addressPrefixes dans la configuration de prédicat de route XForwarded Remote Addr.

Important

Les plages d’adresses IP utilisées par Azure Front Door peuvent changer. Le fichier Plages d'adresse IP Azure et étiquettes de service faisant autorité est publié chaque semaine et consigne toute modification des plages d'adresses IP. Pour vous assurer que votre configuration reste à jour, vérifiez les plages d'adresses IP chaque semaine et mettez à jour votre configuration en fonction des besoins (idéalement, de manière automatisée). Pour éviter les tâches de maintenance associées à cette approche, vous pouvez déployer Azure Spring Apps dans un réseau virtuel avec les autres scénarios décrits avec un NSG et l'étiquette de service AzureFrontDoor.Backend.

Les plages d'adresses IP Azure Front Door étant partagées avec d'autres organisations, vous devez également vous assurer de verrouiller l'accès pour autoriser uniquement votre instance Azure Front Door spécifique, en fonction de l'en-tête HTTP X-Azure-FDID contenant votre Front Door ID unique. Vous pouvez restreindre l'accès en utilisant le prédicat de route Header, celui-ci rejetant une demande sauf si un en-tête HTTP spécifié a une certaine valeur.

Dans ce scénario, la configuration de votre prédicat de route Spring Cloud Gateway peut se présenter comme suit :

(...)
predicates:
- XForwardedRemoteAddr="13.73.248.16/29","20.21.37.40/29","20.36.120.104/29","20.37.64.104/29", ...(and many more)...
- Header="X-Azure-FDID", "e483e3cc-e7f3-4e0a-9eca-5f2a62bde229"

Contributeurs

Microsoft gère ce contenu. Le contributeur suivant a développé le contenu original.

Auteur principal :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes