Deploying a Wildcard Azure Application Gateway using Powershell
Azure Application Gateway esiste ormai da diversi anni. Negli ultimi anni, lo abbiamo visto cambiare dallo Standard originale (V1) senza alcuna funzionalità Web Application Firewall al più recente Standard (V2) con o senza funzionalità WAF. La versione v2 è stata rilasciata il 30 aprile 2019 quindi probabilmente ha già sostituito la maggior parte delle vostre V1 (o se volete iniziare da capo, la V2 è probabilmente la strada da seguire)
Come funziona un Application Gateway?
Solo per ricordare, come funziona esattamente un Azure Application Gateway:
Come illustrato nell’immagine qui sopra, è possibile posizionare un Azure Application Gateway tra i (web)client – per esempio gli utenti che vogliono connettersi al tuo sito web – e i tuoi server backend. I bilanciatori di carico tradizionali operano a livello di trasporto (livello OSI 4 – TCP e UDP) e instradano il traffico in base all’indirizzo IP sorgente e alla porta, verso un indirizzo IP e una porta di destinazione.
Application Gateway può prendere decisioni di routing basate su attributi aggiuntivi di una richiesta HTTP, per esempio il percorso URI o gli header dell’host. Per esempio, è possibile instradare il traffico in base all’URL in entrata. Così, se /images è nell’URL in arrivo, è possibile instradare il traffico a un insieme specifico di server (noto come pool) configurato per le immagini. Se /video è nell’URL, quel traffico viene instradato a un altro pool ottimizzato per i video.
Questo tipo di routing è noto come bilanciamento del carico a livello di applicazione (OSI layer 7). Azure Application Gateway può fare il routing basato su URL e altro ancora. Se vuoi saperne di più su tutte le caratteristiche di un’applicazione, controlla questo sito
Ora introducendo: Wildcard Application Gateway
Quindi, per quelli di voi che hanno distribuito Application Gateway in passato, sia attraverso l’uso di modelli ARM, Azure CLI o Powershell, probabilmente sapranno che il processo di distribuzione di un AGW è piuttosto complicato, soprattutto quando si desidera definire più ascoltatori e/o impostazioni HTTP di backend. Personalmente, in passato ho distribuito Application Gateway che consistevano in 15 ascoltatori e successive impostazioni di backend, tutti terminanti sullo stesso domainname.
Per esempio:
www.contoso.com;
Contoso.com;
My.contoso.com;
Etc.
Il problema con una configurazione come questa è che era un bel po’ di lavoro creare gli ascoltatori, associarli a una regola che a sua volta è associata a un backend e alle impostazioni HTTP. E bisognava farlo per ogni singolo hostname che si voleva configurare, nonostante il fatto che tutti condividessero lo stesso dominio.
Ma dal 20 luglio 2020, Microsoft ha annunciato che ora supporterà anche la possibilità di definire gli hostname jolly in un listener multisito. Ed è possibile utilizzare fino a 5 nomi host unici per ascoltatore. Non è fantastico?
Come funziona esattamente è illustrato di seguito:
Come potete vedere nell’immagine sopra, ci sono più ascoltatori ‘multi-sito’ configurati su questo gateway applicativo:
– *.contoso.com, *.fabrikam.*
– *.contos-*, frabrikam-??.com
Questi ascoltatori possono quindi essere indirizzati allo stesso o a diversi pool di backend.
Quindi, usando un carattere jolly nel nome dell’host, puoi abbinare più nomi di host in un singolo ascoltatore. Per esempio, *.contoso.com può corrispondere a ecom.contoso.com, b2b.contoso.com così come customer1.b2b.contoso.com e così via. Usando un array di nomi di host, è possibile configurare più di un nome di host per un ascoltatore, per instradare le richieste a un pool di backend. Per esempio, un ascoltatore può contenere contoso.com, fabrikam.com che accetterà richieste per entrambi i nomi di host.
I caveat degli ascoltatori jolly
Siccome gli ascoltatori jolly sono attualmente ancora in anteprima, ci sono alcune considerazioni e limitazioni da tenere in considerazione:
1. Questa funzione è in anteprima ed è disponibile solo per Standard_v2 e WAF_v2 SKU di Application Gateway.
2. Questa funzione è attualmente disponibile solo attraverso Azure PowerShell e Azure CLI. Il supporto del portale è in arrivo. Si prega di notare che, poiché il supporto del portale non è completamente disponibile, se si utilizza solo il parametro HostNames, l’ascoltatore apparirà come un ascoltatore di base nel portale e la colonna del nome dell’host della vista elenco dell’ascoltatore non mostrerà i nomi degli host che sono configurati. Per qualsiasi modifica a un listener jolly, assicurati di usare Azure PowerShell o CLI finché non sarà supportato nel portale. Condividerò alcuni screenshot riguardanti questo più avanti in questo blog.
3. Non è possibile creare una regola di reindirizzamento con un listener di destinazione che utilizza wildcard o più nomi host. Quindi non è possibile creare un reindirizzamento da HTTP a HTTPS come si può fare in una configurazione di listener non jolly.
4. Per il controllo della salute del backend, non è possibile associare più sonde personalizzate per le impostazioni HTTP. Invece, puoi sondare uno dei siti web del backend o usare “127.0.0.1” per sondare il localhost del server di backend. Tuttavia, quando si utilizzano caratteri jolly o nomi di host multipli in un listener, le richieste per tutti i modelli di dominio specificati saranno indirizzate al pool di backend a seconda del tipo di regola (di base o basata sul percorso).
5. Non è possibile utilizzare un’espressione regolare per menzionare il nome dell’host. Puoi usare solo caratteri jolly come asterisco (*) e punto interrogativo (?) per formare il modello del nome dell’host.
6. Se più nomi di host sono menzionati nello stesso listener, devi caricare un certificato SAN (Subject Alternative Names) con i CN corrispondenti ai nomi di host menzionati.
7. Se è un nome di host jolly come *.contoso.com, devi caricare un certificato jolly con CN come *.contoso.com
Ecco la teoria! Come faccio a distribuire?
Come detto prima, al momento di scrivere questo blog, puoi usare Powershell o Azure CLI.
Ho costruito un esempio powershell che farà quanto segue:
1. Trova l’approriate VNET e Subnet per distribuire l’AGW in.
2. Crea un indirizzo IP pubblico da utilizzare per l’AGW
3. Crea configurazioni IP per il gateway e il frontend
4. Crea backend-pools
5. Creare gli ascoltatori e le regole di routing
6. Creare la politica del Web Application Firewall
7. Configurare le impostazioni della politica TLS
8. Creare l’application gateway (a questo punto sarà un AGW solo HTTP)
Quindi, dopo che l’AGW è stato distribuito con successo, lo script aggiungerà HTTPS all’application gateway:
9. Trova l’AGW e memorizzalo in una variabile
10. Aggiungi il certificato SSL (PFX + password richiesta) e memorizzalo in una variabile
11. Aggiungi la porta HTTPS del frontend listener e memorizzala in una variabile
12. Ottieni la configurazione IP del frontend e memorizzala in una variabile
13. Aggiungere un ascoltatore frontend (HTTPS) e memorizzarlo in una variabile
14. Ottenere il backendpool e memorizzarlo in una variabile
15. Aggiungi le impostazioni HTTP del backend e memorizzale in una variabile
16. Legare tutto quanto sopra in una Routing Rule
17. Aggiorna l’Application Gateway con tutto ciò che è stato creato nei passi 8-15.
Lo script powershell
Prima di poter eseguire lo script powershell, ci sono alcune cose da fare:
1. Accedi ad Azure, usando powershell (login-azAccount)
2. Trova l’abbonamento che vuoi distribuire (get-azSubscription)
3. Seleziona quell’abbonamento (select-azsubscription -subscription “SUBSCRIPTIONNAME”)
4. Assicurati di aver creato una VNET e una Subnet nel tuo abbonamento, che sia in grado di distribuire AGW. Per il dimensionamento della subnet, l’utilizzo di una subnet /26 è consigliato come minium.
5. Se hai una VNET funzionante e delle subnet distribuite in un gruppo di risorse di tua scelta, riempi i seguenti parametri con le informazioni appropriate:
– Nome del gruppo di risorse della rete virtuale ($VnetRGName)
– Nome della rete virtuale ($VnetName)
– Nome della subnet ($SubnetName)
6. Il resto delle variabili dipende da te. Perché ci potrebbero essere cose coinvolte come convenzioni di denominazione, impostazioni di timeout ecc. Non raccomanderò nulla qui. Il mio script è basato su un singolo listener jolly con un singolo backend e alcune impostazioni http predefinite, ma sentitevi liberi di modificarle a vostro piacimento.
7. Un’attenzione speciale va alle impostazioni WAF & SSL/TLS. Questo script abiliterà il WAF per te e creerà una policy WAF nello stesso gruppo di risorse in cui verrà distribuito l’Application Gateway. Questa politica WAF è poi legata all’AGW. Per le impostazioni SSL/TLS sto abilitando l’ultima preconfigurata (best-practice) policysetting.
Quale sarà il risultato?
Una volta eseguito lo script powershell, ti ritroverai con un gruppo di risorse che ha le seguenti risorse:
1. L’Application Gateway stesso
2. Un indirizzo IP pubblico legato all’Application Gateway
3. Una Web Application Firewall Policy personalizzata legata all’Application Gateway
Spero che questo post ti aiuti a distribuire e configurare il Wildcard Application Gateway che desideri!
Link utili:
Lo script Powershell su github
Documentazione Microsoft
Leave a Reply