Articles / décembre 4, 2021

Déploiement d’une passerelle d’applications Azure Wildcard à l’aide de Powershell

Jorrit Meijer

19 oct, 2020 – 7 min lu

Azure Application Gateway existe depuis pas mal d’années maintenant. Au cours des dernières années, nous l’avons vu évoluer de la norme originale (V1) sans aucune fonctionnalité de pare-feu d’application Web à la norme la plus récente (V2) avec ou sans fonctionnalité WAF. La version v2 a été publiée le 30 avril 2019, elle a donc probablement remplacé la plupart de vos V1 à l’heure actuelle (ou si vous voulez repartir à zéro, la V2 est probablement la voie à suivre)

Logo de Azure Application Gateway

Comment fonctionne une passerelle d’applications ?

Pour rappel, comment fonctionne exactement une passerelle d’applications Azure :

Comme l’illustre l’image ci-dessus, vous pouvez placer une Azure Application Gateway entre les (web)clients – par exemple les utilisateurs qui veulent se connecter à votre site web – et votre ou vos serveurs backend. Les équilibreurs de charge traditionnels fonctionnent au niveau de la couche de transport (couche OSI 4 – TCP et UDP) et acheminent le trafic en fonction de l’adresse IP et du port source, vers une adresse IP et un port de destination.

L’Application Gateway peut prendre des décisions d’acheminement en fonction d’attributs supplémentaires d’une requête HTTP, par exemple le chemin URI ou les en-têtes d’hôte. Par exemple, vous pouvez acheminer le trafic en fonction de l’URL entrant. Ainsi, si /images figure dans l’URL entrant, vous pouvez acheminer le trafic vers un ensemble spécifique de serveurs (appelé pool) configurés pour les images. Si /video figure dans l’URL, ce trafic est acheminé vers un autre pool optimisé pour les vidéos.

Ce type de routage est connu sous le nom d’équilibrage de charge de la couche application (couche 7 de l’OSI). Azure Application Gateway peut effectuer un routage basé sur les URL et bien plus encore. Si vous voulez en savoir plus sur toutes les fonctionnalités d’une application, veuillez consulter ce site

Maintenant introduit : Wildcard Application Gateway

Donc, pour ceux d’entre vous qui ont déployé des passerelles d’application dans le passé, que ce soit par l’utilisation de modèles ARM, Azure CLI ou Powershell, sauront probablement que le processus de déploiement d’une AGW est assez lourd, surtout lorsque vous voulez définir plusieurs auditeurs et/ou paramètres HTTP dorsaux. Personnellement, j’ai déployé par le passé des passerelles d’application qui se composaient de 15 listeners et de paramètres backend ultérieurs, tous se terminant par le même nom de domaine.
Par exemple :
www.contoso.com;
Contoso.com;
Mon.contoso.com;
Etc.

Le problème avec une configuration comme celle-ci est que c’était un travail assez important de créer les listeners, de les associer à une règle qui à son tour est associée à un backend et à un paramètre HTTP. Et vous deviez le faire pour chaque nom d’hôte unique que vous vouliez configurer, malgré le fait qu’ils partageaient tous le même domaine.

Mais depuis le 20 juillet 2020, Microsoft a annoncé qu’ils prendront désormais également en charge l’option de définir des noms d’hôtes génériques dans un écouteur multisite. Et vous pouvez utiliser jusqu’à 5 noms d’hôtes uniques par auditeur. N’est-ce pas génial ?

Alors, comment cela fonctionne exactement est illustré ci-dessous :

Comme vous pouvez le voir dans l’image ci-dessus, il y a plusieurs auditeurs ‘multi-site’ configurés sur cette passerelle d’application :
– *.contoso.com, *.fabrikam.*
– *.contos-*, frabrikam- ??.com
Ces écouteurs peuvent ensuite être acheminés vers les mêmes ou différents pools de backend.
Donc, en utilisant un caractère générique dans le nom d’hôte, vous pouvez faire correspondre plusieurs noms d’hôtes dans un seul écouteur. Par exemple, *.contoso.com peut correspondre à ecom.contoso.com, b2b.contoso.com ainsi qu’à customer1.b2b.contoso.com et ainsi de suite. En utilisant un tableau de noms d’hôtes, vous pouvez configurer plusieurs noms d’hôtes pour un listener, afin d’acheminer les requêtes vers un pool backend. Par exemple, un auditeur peut contenir contoso.com, fabrikam.com qui acceptera les demandes pour les deux noms d’hôtes.

Les mises en garde des auditeurs wildcard

Puisque les auditeurs wildcard sont actuellement encore en preview, il y a quelques considérations et limitations à prendre en compte:
1. Cette fonctionnalité est en phase de prévisualisation et n’est disponible que pour les SKU Standard_v2 et WAF_v2 d’Application Gateway.

2. Cette fonctionnalité n’est actuellement disponible que via Azure PowerShell et Azure CLI. Le support du portail sera bientôt disponible. Veuillez noter qu’étant donné que le support du portail n’est pas entièrement disponible, si vous utilisez uniquement le paramètre HostNames, l’auditeur apparaîtra comme un auditeur de base dans le portail et la colonne Host name de la vue de l’auditeur n’affichera pas les noms d’hôtes configurés. Pour toute modification d’un listener wildcard, assurez-vous d’utiliser Azure PowerShell ou CLI jusqu’à ce qu’il soit supporté dans le portail. Je partagerai quelques captures d’écran à ce sujet plus loin dans ce blog.

3. Vous ne pouvez pas créer une règle de redirection avec un auditeur cible qui utilise des noms d’hôtes génériques ou multiples. Vous ne pouvez donc pas créer une redirection HTTP vers HTTPS comme vous pouvez le faire dans une configuration d’auditeur sans caractère générique.

4. Pour le contrôle de santé du backend, vous ne pouvez pas associer plusieurs sondes personnalisées par paramètres HTTP. Au lieu de cela, vous pouvez sonder l’un des sites Web du backend ou utiliser « 127.0.0.1 » pour sonder le localhost du serveur backend. Cependant, lorsque vous utilisez un caractère générique ou plusieurs noms d’hôtes dans un auditeur, les demandes pour tous les modèles de domaine spécifiés seront acheminées vers le pool backend en fonction du type de règle (de base ou basée sur le chemin).

5. Vous ne pouvez pas utiliser une expression régulière pour mentionner le nom d’hôte. Vous pouvez uniquement utiliser des caractères génériques comme l’astérisque (*) et le point d’interrogation ( ?) pour former le modèle de nom d’hôte.

6. Si plusieurs noms d’hôte sont mentionnés dans le même auditeur, vous devez télécharger un certificat SAN (Subject Alternative Names) avec les CN correspondant aux noms d’hôte mentionnés.

7. S’il s’agit d’un nom d’hôte générique comme *.contoso.com, vous devez télécharger un certificat générique avec CN comme *.contoso.com

Assez avec la théorie ! Comment puis-je déployer?

Comme mentionné précédemment, au moment d’écrire ce blog, vous pouvez soit utiliser Powershell ou Azure CLI.

J’ai construit un exemple powershell qui fera ce qui suit:
1. Trouver le VNET et le sous-réseau appropriés pour déployer l’AGW dans.
2. Créer une adresse IP publique à utiliser par l’AGW
3. Créer des configurations IP pour la passerelle et le frontend
4. Créer des backend-pools
5. Créer des listeners et des règles de routage
6. Créer une politique de Web Application Firewall
7. Configurer les paramètres de la politique TLS
8. Créer la passerelle d’application (à ce stade, ce sera une AGW uniquement HTTP)

Puis, après que l’AGW ait été déployée avec succès, le script ajoutera HTTPS à la passerelle d’application:

9. Trouver l’AGW et le stocker dans une variable
10. Ajouter le certificat SSL (PFX + mot de passe requis) et le stocker dans une variable
11. Ajouter le port d’écoute du frontend HTTPS et le stocker dans une variable
12. Obtenir la configuration IP du frontend et la stocker dans une variable
13. Ajouter un écouteur frontal (HTTPS) et le stocker dans une variable
14. Obtenir le backendpool et le stocker dans une variable
15. Ajouter les paramètres HTTP du backend et les stocker dans une variable
16. Lier tout ce qui précède dans une règle de routage
17. Mettez à jour la passerelle d’application avec tout ce qui a été créé aux étapes 8-15.

Le script powershell

Avant de pouvoir exécuter le script powershell, il y a quelques choses que vous devez faire :

1. Connectez-vous à Azure, en utilisant powershell (login-azAccount)

2. Trouvez la souscription que vous voulez déployer dans (get-azSubscription)

3. Sélectionnez cette souscription (select-azsubscription -subscription « SUBSCRIPTIONNAME »)

4. Assurez-vous que vous avez ce qui suit créé un VNET et un sous-réseau dans votre souscription, qui est capable de déployer l’AGW dans. Pour le dimensionnement du sous-réseau, l’utilisation d’un sous-réseau /26 est recommandée comme minium.

5. Si vous avez un VNET fonctionnel et des sous-réseaux déployés dans un groupe de ressources de votre choix, remplissez les paramètres suivants avec les informations appropriées :
– Nom du groupe de ressources du réseau virtuel ($VnetRGName)
– Nom du réseau virtuel ($VnetName)
– Nom du sous-réseau ($SubnetName)

6. Le reste des variables dépend vraiment de vous. Parce qu’il pourrait y avoir des choses impliquées comme la convention de dénomination, les paramètres de timeout, etc. Je ne recommanderai rien ici. Mon script est basé sur un seul listener wildcard avec un seul backend et quelques paramètres http par défaut, mais n’hésitez pas à les modifier à votre goût.

7. Une attention particulière est accordée aux paramètres SSL/TLS du WAF &. Ce script activera le WAF pour vous et il créera une politique WAF dans le même groupe de ressources que celui dans lequel la passerelle d’application sera déployée. Cette politique WAF est ensuite liée à l’AGW. Pour les paramètres SSL/TLS, j’active le dernier policysetting préconfiguré (meilleure pratique).

Quel sera le résultat ?

Une fois que vous avez exécuté le script powershell, vous vous retrouverez avec un groupe de ressources qui a les ressources suivantes :

Universe