Azure – Application Security Groups

Azure – Application Security Groups

Security is not something to kid about and when it comes to cloud, you have to be very through when you’re deploying your cloud infrastructure. Which means that you are still required to do defense in depth, use anti-malware systems, configure extended monitoring, logging and reporting mechanisms. When you’re going to the cloud, you have to be aware of the Shared Responsibility Matrix which applies to any cloud provider.

As you can see in the image above, you as a customer still have a responsibility to secure your cloud environment. So those skills you’ve developed while working on-premises will still be of value in the cloud.

The subject for today’s topic is managing Network Security Groups using a feature in Azure, called Application Security Groups.

What are they?

Application Security Groups are a mechanism to group virtual machines that reside in the same virtual network and apply Network Security Groups to them.

The way you deployed NSGs in Azure subscription was that you would assign them to a network interface or a subnet and then configure them in a granular manner, based on the deployment type. The reality was that it’s utopic to do this cleanly and it gets messy after a couple of months. So ASGs came to the rescue where it helped you group a set of VMs based on roles like Web, DB, Middleware etc. and apply NSG Allow / Deny rules on them.

By using an ASG, you simply your management overhead by just adding the VMs that you create in those groups and automatically you get the security policies applied from your NSG.

ASG Example – Source Ignite

Getting Started

Creating / using Application Security Groups is easy. Go to the Azure Portal -> Create a resource -> Type in Application Security Group and press create.

Or you can simply use Powershell

After you’ve created the ASG, the next thing that you need to do is to assign it to some VMs, which can be done via the Portal or PS.

Next step is to add or modify your inbound / outbound rules to use those new ASGs you’ve created. Doing that is very simple and you can also do it via the portal or CLI.

As you can see, it’s pretty easy to secure your VMs, and considering that it can become a pain to manage the NSGs even for simple deployments. I’m not even talking about very complex ARM deployments which deploy tens of VMs and link them together 🙂

NSG in ARM Template – Little nugget to be careful of

A friend of mine was having issues connecting to a couple of VMs that he provisioned using an ARM template. The template worked perfectly until he added the JSON block to add an NSG.

Every time he started a deployment with the NSG block in the ARM template, he wouldn’t be able to connect to the VMs in any way. The fun fact was that even deleting the NSG didn’t solve the issue, so he had to recreate the whole environment from scratch and trust me that took a while 🙂

So what was the problem, you may ask?

He was using a source TAG Internet which for some reason (I still haven’t figured this one out), killed the connectivity on the VMs on both sides (Private and Public IPs) and funnily enough, the logs didn’t show anything.

If you encounter a problem like this one, double check your NSG blocks to not have sourceAddressPrefix: Internet but sourceAddressPrefix: *

Problematic example:

Working example:

So far I haven’t been able to reproduce it, and I’m still looking into what’s causing the issue for that particular ARM template but if you encounter something similar, give it a try and let me know your findings 🙂

Have a good one!

Pin It on Pinterest