Azure Networking: le novità dell’Azure Application Gateway v2

Azure Application Gateway (Application Delivery Controller as-a-service) è un load balancer applicativo (layer 7) con integrate funzionalità di firewall web, per erogare funzionalità di application delivery. Recentemente Microsoft ha annunciato la disponibilità di una nuova release di Azure Application Gateway e Web Application Firewall (WAF), si tratta della nuova SKU versione 2 (Standard_v2 e WAF_v2). Con questo articolo andremo ad elencare le nuove funzionalità presenti, con alcuni approfondimenti di dettaglio per quelle ritenute maggiormente interessanti.

Nuove funzionalità

Le nuove funzionalità presenti nella SKU v2 di Azure Application Gateway Standard e WAF permettono la configurazione delle regole di ripubblicazione esterna, per i servizi web (HTTP/HTTPS), con maggiore semplicità, sicurezza e flessibilità.

Figura 1 – Riepilogo nuove funzionalità

Si riportano alcune delle funzionalità introdotte dalla nuova SKU.

IP statico

Come per il Load Balancer di tipo Public è ora possibile assegnare in fase di deploy un IP pubblico (VIP) statico. Non si avrà quindi più la problematica del possibile cambio di IP in seguito ad un restart dell’Application Gateway. Non sarà neanche più necessario eseguire la registrazione di un record DNS pubblico di tipo CNAME (ALIAS) invece che un record di tipologia A.

Comunicazione SSL tra Application Gateway e Backend

La SKU v2, a differenza della precedente versione, non necessita più dell’importazione del certificato in formato .cer nella configurazione degli HTTP settings. Per il funzionamento end-to-end basta semplicemente configurare gli HTTP settings con protocollo di tipo HTTPS. In automatico verrà riconosciuto valido il certificato associato al backend se questo risulterà essere rilasciato da una trusted root attendibile (well-known).

E’ comunque possibile importare certificati trusted root non considerate “well-known” oppure certificati di tipologia self-signed.

URL rewrite

Grosso limite nella versione v1 era l’impossibilità di gestire qualsiasi tipologia di URL Rewrite. Questo costringeva, in caso di necessità, a dover eseguire configurazioni a livello di backend tramite opportuni moduli (esempio IIS url rewrite). Nella SKU v2 dell’Application Gateway è ora possibile, in modo centralizzato, configurare l’URL Rewrite.

 

Figura 2 – URL rewrite

Ci sono diverse tipologie e regole di rewrite supportate, ma lo scenario più comune è sicuramente la ripubblicazione di una App Service Web App tramite Azure Application Gateway per la raggiungibilità dall’esterno.

Ormai noto è il problema dei link interni all’App Service Web App che senza un’opportuna configurazione, lato Application Gateway, generava da parte dell’utente finale l’accesso, non più tramite ripubblicazione, ma direttamente verso la Web App. Questo comportava di fatto la comunicazione tra il client e la Web App bypassando tutta la messa in sicurezza data dalla ripubblicazione, tramite Application Gateway, del servizio web su Internet. Utilizzando la URL Rewrite è ora possibile modificare questo comportamento gestendo la risposta del backend. Tramite opportuna regola di rewrite si andrà a sostituire *.azurewebsties.net con il custom public domain previsto da configurazione, come riportato in seguito:

Figura 3 – URL rewrite HTTP Header – Condition
Figura 4 – URL rewrite HTTP Header – Action

Integrazione con Azure Key Vault

Risulta ora possibile, oltre alla configurazione classica che prevede l’importazione e associazione nel Listener del certificato con la chiave privata, anche l’integrazione con l’Azure Key Vault. Durante la configurazione del Listener sarà possibile dare come riferimento l’oggetto certificato salvato all’interno del Key Vault. In questo momento la funzionalità è in public preview e la configurazione risulta possibile solo tramite Azure Powershell o CLI.

Scalabilità automatica e Ridondanza della zona

Nella nuova SKU è possibile configurare in fase di deployment la dimensione impostando il numero di istanze previste. Inoltre c’è in alternativa la possibilità di prevedere la scalabilità automatica in modo che, a seconda del carico di lavoro, venga fatto in automatico uno scale-up o scale-down del numero delle istanze in utilizzo.

Il vantaggio della configurazione di tipologia dinamica (autoscale) rispetto a quella fissa (manual) è chiaramente dato da scenari di gestione di workload che non hanno un carico di lavoro preciso e omogeneo nel tempo senza mai subire variazioni.

 

Figura 5 – Impostazioni di Autoscale

E’ anche possibile prevedere la distribuzione dell’Application Gateway su più zone separate di disponibilità (availability zone) in modo da non essere soggetti a disservizi in caso di problematiche legate alla singola zona (single point of failure).

Figura 6 – Availability Zone

Performance

Per ultimo ma non meno importante sono state dichiarate notevoli migliorie dal punto di vista delle performance. Sia lato gestione dell’offloading (fino a 5 volte superiore rispetto alla precedente SKU) che lato tempistiche, da sempre un punto dolente, considerando i tempi di esecuzione decisamente considerevoli nella fase di deployment e modifica delle configurazioni.

Region supportate

Ad oggi Azure Application Gateway Standard_v2 e WAF_v2 risultano disponibili nelle seguenti region: North Central US, South Central US, West US, West US 2, East US, East US 2, Central US, North Europe, West Europe, Southeast Asia, France Central, UK West, Japan East, Japan West.

Limiti della soluzione

Queste le limitazioni riportate rispetto alla precedente SKU v1.

Difference Details
Authentication certificate Not supported.
For more information, see Overview of end to end SSL with Application Gateway.
Mixing Standard_v2 and Standard Application Gateway on the same subnet Not supported
User Defined Route (UDR) on Application Gateway subnet Not supported
NSG for Inbound port range – 65200 to 65535 for Standard_v2 SKU
– 65503 to 65534 for Standard SKU.
For more information, see the FAQ.
Performance logs in Azure diagnostics Not supported.
Azure metrics should be used.
Billing Billing scheduled to start on June 1, 2019.
FIPS mode These are currently not supported.
ILB only mode This is currently not supported. Public and ILB mode together is supported.
Netwatcher integration Not supported.

Riferimenti

Si riportano alcuni documenti ritenuti utili per ulteriori approfondimenti:

Conclusioni

Azure Application Gateway Standard v2 e Web Application Firewall v2 risultano ora disponibili per essere utilizzati in ambienti di produzione. Le nuove funzionalità hanno portato notevoli migliorie sotto vari fronti: sicurezza, gestione, flessibilità e performance. A questo punto non resta che adottarli per sfruttare a pieno le nuove funzionalità introdotte.