In this post, I will describe a preview feature of Network Security Groups, called Application Security Groups, which allows you dynamically assign firewall policies to groups of Azure virtual machines.
Azure has a built-in, distributed Layer-4 stateful firewall system called Network Security Groups (NSGs). An NSG is a firewall policy, defining a collection of inbound and outbound allow or deny rules for network traffic. A collection of default rules are included and administrators typically add inbound rules to allow traffic into applications or services running on virtual machines, and optionally add outbound rules to control data leakage.
NSGs can be and are by default in the Azure Portal, assigned to the NICs of virtual machines on a 1:1 basis but that doesn’t really scale well. Instead, we should create and assign NSGs at the subnet level. The source and destinations in the firewall rules can be tags/locations such as Azure SQL,Virtual Network, or a network/specific address.
When we create inbound rules, it is recommended that we be as specific as possible with the destination address. In a well-structured virtual network, each subnet is treated as a security domain. For example, the subnet 10.0.1.0/24 might be the web server subnet and an NSG might allow TCP 443 into 10.0.1.0/24. However, some (including Azure Security Center’s recommendations) would prefer that individual machine addresses were specified as the destination instead.
The problem with the best practice specific destination approach is that systems change. Let’s assume that you have created rules to allow traffic into 4 virtual machines: 10.0.1.4, 10.0.1.5, 10.0.1.6, and 10.0.1.7. That’s great for your regular load of web servers. But what if you enabled Auto-Scaling?
Auto-Scaling will dynamically add and reduce the number of web servers in your deployment based on a set of administrator-defined rules. If demand for the application increases, the number of web servers increase. If demand subsides, the number of web servers decreases. In the case of an increase, new web servers will appear with the next available IP addresses in the subnet. Someone is going to have to add those IP addresses to the NSG rules.
Maybe I didn’t create a “web server” subnet. Maybe it’s a subnet with lots of machines coming and going, so I have no idea what IP addresses the web servers will have.
How many of your servers’ IP addresses do you know without looking them up? I can remember 3 phone numbers, so I haven’t a hope of recalling the addresses of an n-tier application. What if we could refer to our machines with some kind of network label?
Even if I wasn’t using Auto-Scaling, it would be much easier and quicker for me to say, “these machines are web servers – allow traffic into all of them”. And if I created a new web server, I would like an easy way to extend the policy to it, without figuring out the IP address, more so if I’m working with dynamic IP addresses.
Microsoft has added a new feature to NSGs called Application Security Groups. This is an opt-in preview requiring you to register the ARM providers at the time of writing. With this feature you can:
Step 4 is repeated for each web server that is created. Without having to know any IP addresses, secure web traffic is being allowed into specific machines only. More web servers can be added, and by the network interfaces being members of webservers, the inbound security rule is dynamically applied to the new machines.
At this time, the following restrictions apply: