Ever heard of the azure application gateway? No… I understand. It is (strangely enough) a component that is often overlooked. In essence, what does it do? Look at it as a load balancer on security steroids. The basic form will help you in terms of SSL offloading, where the advanced form will turn it into a WAF.
Now, when do we use it? The last case I used it was when I was setting up Rancher on Azure. This is by far the best container management software out there! Though it has one downside, it does not provide SSL by itself. So you need to look at an external solution for that. Often people fall back to things like haproxy or nginx. Though with Azure, we have a great (managed) service called the “Application Gateway”. So why not use that one? 😉
Let us take a look at the Azure configuration for our Application Gateway. So I’ve configured it to have one node (use more for production!) and to act as a WAF. Here I’ve enabled to firewall and set it to “Prevention”.
In terms of networking, I have one VNET with three subnets ;
- SUBNET000 : My application payload resides here
- SUBNET254 : This is typically my DMZ subnet.
- SUBNETAGW01 : An application gateway requires his/her own subnet…
And here we can see that both workloads are seperated in terms of subnets. So I can lock it down with NSGs!
Now back to the application gateway. I have the node in my backend pool.
And my http settings have a custom probe…
Why did I configure this as follows… Check my last post! 😉 The default probe will check the root “/” and this will return a value that is not within the acceptable range, due to not being logged in. When we trigger the login page, we will get a status code within the acceptable range.
And we’ve added the certificate the the HTTPS Listener config.
So now we have a nice & secure rancher deployment!
In need of certificates? You have several options ;
- https://letsencrypt.org/ – Free, an alternative / custom integration is needed on your web server, does not work with the application gateway
- https://www.startssl.com/ – Free, the common approach is done here
- https://www.digicert.com/ – Paid, one I often come across in enterprises
So feel free to choose what you like…. For this demo, I used StartSSL and that worked great.
10 thoughts on “Azure Application Gateway : Often overlooked…”
Sidenote when using it for rancher ; https://github.com/rancher/rancher/issues/6328
Hi there, what are pros/cons between Application Gateway and Nginx (azure market place) ?
The application gateway relieves your of the management of the platform/service. It’s “PaaS”, where deploying nginx is on top of a virtual machine (IaaS). Here you have to manage the VM & the OS, where with the application gateway you “just” have to manage the configuration (rules etc) .
My problem with Azure Application Gateway(AAGw) is this
1. If you already have an environment with web, app and db subnet/tier and you want to introduce AAGw, YOU HAVE TO CREATE ITS OWN NEW VNET AND SUBNET.
And then peer vnets with your network on azure.
It needs its own dedicated subnet. Though it can share a subnet… It has always been like that.
It also doesn’t protect against DDOS.
Netork based DDOS is part of the network fabric and included with all services. You can upgrade the App GW to a WAF and then you can close the gap with the underlying OWASP rule set.
Though you are free to roll out your F5 (or any other) in a VM, if you feel better that way. 😉
Thanks. Nice post to show other how to use AppGW 😉
This is a nice article, thx for it.
Probably you have noticed that you can expierience issues when accessing logs and shells through rancher UI.
Unfortunately it works sometimes when you open the logs and shell windows in popup windows (press ctrl key) but not all times.
It seems that some websocket connections do not work e.g logging:
Edit: This only occurs if local authentication is enabled.