Een Wildcard Azure Application Gateway implementeren met Powershell
Azure Application Gateway bestaat al een flink aantal jaren. In de afgelopen jaren hebben we het zien veranderen van de oorspronkelijke standaard (V1) zonder enige Web Application Firewall-functionaliteit naar de meest recente standaard (V2) met of zonder WAF-functionaliteit. De v2-versie is uitgebracht op 30 april 2019, dus waarschijnlijk heeft deze de meeste van uw V1’s inmiddels vervangen (of als u fris wilt beginnen, is de V2 waarschijnlijk de weg vooruit)
Hoe werkt een Application Gateway?
Om u eraan te herinneren, hoe werkt een Azure Application Gateway precies:
Zoals geïllustreerd in de afbeelding hierboven, kunt u een Azure Application Gateway plaatsen tussen (web)clients – bijvoorbeeld gebruikers die verbinding willen maken met uw website – en uw backend server(s). Traditionele load balancers werken op de transportlaag (OSI laag 4 – TCP en UDP) en routeren verkeer op basis van bron IP-adres en poort, naar een bestemming IP-adres en poort.
Application Gateway kan routeringsbeslissingen nemen op basis van aanvullende attributen van een HTTP-verzoek, bijvoorbeeld URI-pad of host headers. U kunt bijvoorbeeld verkeer routeren op basis van de inkomende URL. Dus als /images in de inkomende URL staat, dan kun je verkeer routeren naar een specifieke set servers (bekend als een pool) die geconfigureerd zijn voor afbeeldingen. Als /video in de URL staat, wordt dat verkeer gerouteerd naar een andere pool die is geoptimaliseerd voor video’s.
Dit type routing staat bekend als applicatie laag (OSI laag 7) load balancing. Azure Application Gateway kan URL-gebaseerde routing doen en nog veel meer. Als u meer wilt weten over alle functies die een applicatie heeft, kijk dan op deze site
Nu introduceren: Wildcard Application Gateway
Diegenen onder u die in het verleden Application Gateways hebben ingezet, hetzij via het gebruik van ARM templates, Azure CLI of Powershell, zullen waarschijnlijk weten dat het proces van het inzetten van een AGW nogal omslachtig is, vooral wanneer u meerdere listeners en/of backend HTTP-instellingen wilt definiëren. Persoonlijk heb ik in het verleden Application Gateways geïmplementeerd die bestonden uit 15 listeners en daaropvolgende backend instellingen, allemaal eindigend op dezelfde domeinnaam.
Bijv.:
www.contoso.com;
Contoso.com;
My.contoso.com;
Etc.
Het probleem met zo’n setup is dat het nogal wat werk was om de listeners te maken, ze te koppelen aan een rule die op zijn beurt weer gekoppeld is aan een backend en HTTP-instelling. En dat moest je doen voor elke hostname die je wilde configureren, ondanks het feit dat ze allemaal hetzelfde domein deelden.
Maar sinds 20 juli 2020 heeft Microsoft aangekondigd dat ze nu ook de optie ondersteunen om wildcard hostnames te definiëren in een multi-site listener. En je kunt tot 5 unieke hostnamen per listener gebruiken. Geweldig toch?
Hoe dat precies werkt, ziet u hieronder:
Zoals u in de bovenstaande afbeelding kunt zien, zijn er meerdere ‘multi-site’ listeners geconfigureerd op deze application gateway:
– *.contoso.com, *.fabrikam.*
– *.contos-*, frabrikam-??.com
Deze listeners kunnen dan worden gerouteerd naar dezelfde of verschillende backend pools.
Dus, gebruikmakend van een wildcard karakter in de hostnaam, kun je meerdere hostnamen matchen in een enkele listener. Bijvoorbeeld, *.contoso.com kan overeenkomen met ecom.contoso.com, b2b.contoso.com zowel als customer1.b2b.contoso.com enzovoort. Met behulp van een array van hostnamen, kun je meer dan één hostnaam voor een listener configureren, om verzoeken naar een backend pool te routeren. Bijvoorbeeld, een luisteraar kan contoso.com, fabrikam.com bevatten die verzoeken voor beide hostnamen zal accepteren.
De caveats van wildcard listeners
Omdat wildcard listeners momenteel nog in preview zijn, zijn er enkele overwegingen en beperkingen om rekening mee te houden:
1. Deze functie is in preview en is alleen beschikbaar voor Standard_v2 en WAF_v2 SKU van Application Gateway.
2. Deze functie is momenteel alleen beschikbaar via Azure PowerShell en Azure CLI. Portal ondersteuning is binnenkort beschikbaar. Houd er rekening mee dat aangezien portal ondersteuning nog niet volledig beschikbaar is, als u alleen de HostNames parameter gebruikt, de listener zal verschijnen als een Basic listener in de portal en de Host name kolom van de listener list view zal niet de hostnamen tonen die zijn geconfigureerd. Voor elke wijziging aan een wildcard listener, zorg ervoor dat je Azure PowerShell of CLI gebruikt totdat het ondersteund wordt in de portal. Ik zal een aantal screenshots hierover verderop in deze blog delen.
3. Je kunt geen redirection rule maken met een target listener die wildcard of meerdere hostnamen gebruikt. U kunt dus geen HTTP-naar-HTPS-omleiding maken zoals u kunt in een luisteraar setup zonder wildcard.
4. Voor backend health check, kunt u niet meerdere aangepaste sondes per HTTP-instellingen koppelen. In plaats daarvan kun je een van de websites op de backend benaderen of “127.0.0.1” gebruiken om de localhost van de backend server te benaderen. Echter, wanneer je wildcard of meerdere host namen gebruikt in een listener, zullen de verzoeken voor alle gespecificeerde domein patronen worden gerouteerd naar de backend pool, afhankelijk van het regel type (basic of path-based).
5. U kunt geen reguliere expressie gebruiken om de hostnaam te vermelden. U kunt alleen wildcard-tekens zoals asterisk (*) en vraagteken (?) gebruiken om het hostnaampatroon te vormen.
6. Als meerdere hostnamen in dezelfde listener worden genoemd, moet u een SAN-certificaat (Subject Alternative Names) uploaden met de CNs die overeenkomen met de genoemde hostnamen.
7. Als het een wildcard-hostnaam is zoals *.contoso.com, moet u een wildcard-certificaat uploaden met CN zoals *.contoso.com
Genoeg over de theorie! Hoe implementeer ik het?
Zoals eerder vermeld, op het moment van schrijven van deze blog, kunt u gebruik maken van Powershell of Azure CLI.
Ik heb een powershell voorbeeld gebouwd dat het volgende zal doen:
1. Zoek het juiste VNET en Subnet om de AGW in te implementeren.
2. Maak een publiek IP adres aan voor de AGW
3. Maak IPconfiguraties voor Gateway en frontend
4. Maak backend-pools
5. Maak listeners en routing regels
6. Maak Web Application Firewall beleid
7. Configureer TLS beleid instellingen
8. Maak de applicatie gateway (op dit punt zal het een HTTP only AGW zijn)
Toen de AGW succesvol is uitgerold, zal het script HTTPS toevoegen aan de applicatie gateway:
9. Zoek de AGW en sla het op in een variabele
10. Voeg het SSL certificaat toe (PFX + wachtwoord vereist) en sla het op in een variabele
11. Voeg de HTTPS frontend luisterpoort toe en sla het op in een variabele
12. Verkrijg de frontend IP configuratie en sla het op in een variabele
13. Voeg een frontend luisteraar (HTTPS) toe en sla het op in een variabele
14. Verkrijg de backendpool en sla het op in een variabele
15. Voeg Backend HTTP instellingen toe en sla het op in een variabele
16. Bind al het bovenstaande samen in een Routing Regel
17. Update de Application Gateway met alles wat in stap 8-15 is gemaakt.
Het powershell script
Voordat u het powershell script kunt uitvoeren, zijn er een paar dingen die u moet doen:
1. Login op Azure, met powershell (login-azAccount)
2. Zoek het abonnement waarin u wilt deployen (get-azSubscription)
3. Selecteer dat abonnement (select-azsubscription -subscription “SUBSCRIPTIONNAME”)
4. Zorg ervoor dat u een VNET en Subnet in uw abonnement heeft aangemaakt, waarin u de AGW kunt deployen. Voor subnet sizing, wordt het gebruik van een /26 subnet aanbevolen als minimum.
5. Als je een werkend VNET hebt en subnetten in een resourcegroup van je keuze, vul dan de volgende parameters met de juiste informatie:
– Virtual Network ResourceGroup name ($VnetRGName)
– Virtual Network Name ($VnetName)
– SubnetName ($SubnetName)
6. De rest van de variabelen is echt aan jou. Omdat er dingen bij kunnen komen kijken zoals naamgeving conventie, timeout instellingen etc. Ik zal hier niets aanbevelen. Mijn script is gebaseerd op een enkele wildcard listener met een enkele backend en enkele standaard http instellingen, maar voel je vrij om deze aan te passen naar je eigen wensen.
7. Speciale aandacht gaat uit naar de WAF & SSL/TLS instellingen. Dit script zal WAF voor u inschakelen en het zal een WAF beleid aanmaken in dezelfde resourcegroep als waarin de Application Gateway zal worden ingezet. Dit WAF beleid is dan gekoppeld aan de AGW. Voor SSL/TLS instellingen zet ik de laatste voorgeconfigureerde (best-practice) beleidsinstelling aan.
Wat zal het resultaat zijn?
Als je het powershell script hebt uitgevoerd, krijg je een resource groep met de volgende resources:
1. De Application Gateway zelf
2. Een publiek IP-adres dat is gekoppeld aan de Application Gateway
3. Een aangepast Web Application Firewall-beleid dat is gekoppeld aan de Application Gateway
Ik hoop dat dit bericht u helpt bij het implementeren en configureren van de Wildcard Application Gateway die u wilt!
Nuttige links:
Het Powershell-script op github
Microsoft-documentatie
Leave a Reply