Service Tags for Azure Network Security Groups

While you are creating NSG rules have you ever faced a scenario where you need to group a bunch of IP addresses, sources or destinations? Service Tags in Azure denotes a group of IP address prefixes that can help you to simplify the NSG rule creation. Service Tags allow you to restrict (allow or deny) traffic to a specific Azure service both globally or per region.

Microsoft manages and updates the list of undelying IP address for each service tag thus eliminating the need to manually update your NSG rule each time the service endpoint IP addresses are changed. This allows you to leverage service tags insteadof  of specific IP addresses when creating security rules.

What’s available right now?

Following is the list of  service tags that are available to be used in a security rule definition.

Azure Service Tag Purpose
VirtualNetwork (Resource Manager) (VIRTUAL_NETWORK for classic): VNet address space (all CIDR ranges defined in the VNet), all connected on-premises address spaces, and peered VNets or VNets connected to a VNet gateway, are encompassed in this service tag.
AzureLoadBalancer (Resource Manager) (AZURE_LOADBALANCER for classic) If you are using any Internet facing Azure Load Balancer you can use this service tag. This tag translates to an Azure datacenter IP address where Azure’s health probes originate.
Internet (Resource Manager) (INTERNET for classic) Any ingress or egress traffic from IP addresses that are outside the VNet and reachable from the Internet, is encompassed in this service tag. The address range includes the Azure owned public IP address space as well.
AzureTrafficManager (Resource Manager only) The IP address space for the Azure Traffic Manager probe IPs is denoted by this service tags.
Storage (Resource Manager only) Azure Storage service IP range is denoted in this service tag so that once you specify Storage for the value, traffic is allowed or denied to storage. Furthermore, you can specify the region to allow or deny traffic to a storage in a specific region.This tag represents the Azure Storage service, but not specific instances of the service (storage accounts).
Sql (Resource Manager only) Address prefixes of the Azure SQL Database and Azure SQL Data Warehouse services are denoted in this service tag. Specifying Sql for the value allows you to allow or deny traffic to Sql. Regional restrictions are possible as in Storage service tag and also this tag represents the Azure SQL service not individual instances. (databases or data warehouses)

Here is an example of a service tag in action. As you can see we are using the Internet service tag to denote all inbound external traffic in this NSG rule.

Monitoring Azure Blobs with Azure Logic Apps

Azure Logic Apps is a very useful service that allows you to perform various enterprise integration tasks, process automation with on-premises and cloud tools a like. In this blog post I’m going to explain how we can leverage Azure Logic Apps to monitor Azure Blob containers. 

The Requirement

I have a blob container called fx-incoming-files that needs to periodically checke for any file that is older than 30 minutes. If any file that has been in the container for 30 minutes or more I need to alert the help desk.

Designing the Logic App

Following is the designer view of the Logic App that I have created. Let’s dissect each step in detail.

  • The recurrence action runs the logic app every 30 minutes.
  • Next step is to list all the blobs in the fx-incoming-files container. We are using List Blobs action for this.
  • First we need to check whether there are any files present in the container. Here is the condition to check that.
@greater(length(body('List_blobs_of_fx-incoming-files')?['value']), 0)
  • If the condition is met we need to check the condition of file age < 30 minutes. Here is the code for that condition. This check whether the last modified date/time for any blob is greater than 30 minutes than the current date/time.
@greater(addMinutes(utcNow(), -30), item()?['LastModified'])
  • Next action creates an HTML table from the body of the result of the previous step.
  • Next action is an Office 365 action which sends an email with the result from the previous step in the body of the email. Note that we need to select Is HTML to True so that the email would render properly with the HTML content.

As you can see all it needs is to figure out the correct connector and/or actions to use in your process flow. You can find the list of available connectors for Azure Logic Apps from this link.