How Do I Apply NSG Policies To Applications in Azure?

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.
 

Network Security Groups

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.

A Problem with Dynamism

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.

Beyond Addresses

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.

Application Security Groups

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:

1. You create an Application Security Group. For example, we create one called webservers.
2. Then you create an NSG.
3. Create an inbound security rule to allow TCP 443 with Internet as the source tag and the Application Security Group, webservers, as the destination.
4. Create a new virtual network interface with membership of the webservers Application Security Group and create a web server with this network adapter.

 
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.

Some Restrictions

At this time, the following restrictions apply:

• All network interfaces in an Application Security Group must be connected to the same virtual network.
• If you specify Application Security Groups as the destination and source of an NSG rule, then the source and destination network interfaces must also be in the same virtual network.
• You must use either Azure CLI or PowerShell to deploy Application Security Groups. An “unmanageable” object for the Application Security Group does appear in the resource group in the Azure Portal.
• At this time, it appears (I haven’t found a workaround yet) that a network interface can only join an Application Security Group when you create the network interface.