- Azure Sentinel—A real-world example - Tue, Oct 12 2021
- Deploying Windows Hello for Business - Wed, Aug 4 2021
- Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021
The core of hosting resources in Azure is your virtual network (vNet). You must connect all of your infrastructure-as-a-service (IaaS) virtual machines (VMs) to a vNet. Increasingly, you can connect other platform-as-a-service (PaaS) resources in Azure as well. But you wouldn't start setting up a new branch office for your business by deploying client PCs—you'd get the wired or wireless network in place first. Similarly, when you start your journey to Azure, networking is the first step.
Onur wrote two good articles on how to create and manage network security groups (NSGs) and ASGs with PowerShell here and here. Think of NSGs as a software-defined firewall that you can define once and apply to a subnet in a vNet or to network interface controllers (NICs) in VMs.
Securing public endpoints
Microsoft designed all Azure services (just like all Office 365 services) for direct internet access—they've all got public endpoints.
The problem this causes (that the new options in this article address) is that when you use NSGs to secure your Azure resources, you had to create complex rules. For instance, for most of your IaaS VMs, you probably don't want to allow traffic out to the internet that originated on the server (i.e., wasn't a response to a legitimate client request).
No problem—just pop a rule in your NSG to deny traffic to the internet. Except…the underlying storage of those VMs along with other services are also on the "internet." The solution up until now was to have an exception rule that contained every single public IP address for every single Azure data center to allow this traffic. This is painful to manage, especially since those addresses change from time to time.
The other issue (sometimes a deployment blocker for security-conscious companies) is that public access means an administrator can access storage or other PaaS services from a home network since they have the correct credentials.
Finally, if you forced all traffic from your Azure vNet to tunnel back to on-premises networks for inspection by your edge firewall, that literally meant all traffic, including Storage and Azure SQL traffic, would go from Azure to your network and then back to Azure. This is clearly not optimal routing.
Released in preview at Ignite and in general availability (GA) on February 1, 2018 (for Storage only) is the solution to these problems: vNet service endpoints. This feature now gives you a way to configure Azure Storage and Azure SQL (still in preview) access without having to open your vNet to public access.
You can only define service endpoints on Azure Resource Manager (ARM) vNets, not old-style Azure Service Management (ASM) vNets. You can also set them on subnets in vNets. You can enable this for new vNets or existing ones and configure the location for the endpoint to match the vNet's region.
Here I'm creating a new vNet (click New > Networking > Virtual network) and only allowing it connectivity to Azure Storage.
Creating a vNet with service endpoints
To check whether this worked, I look in Service endpoints for the vNet. Note that you can add more service endpoints here on a per-subnet basis if required. Also note in the screenshot that even though my vNet is in Australia East, the endpoint has also added Australia Southeast for high availability.
List of service endpoints in the vNet
If you look at the Effective routes on a deployed VM's NIC, it'll list the endpoints under Next Hop Type. Be aware that enabling this on existing VMs will interrupt network traffic momentarily as it rebuilds the route table, so schedule this for a maintenance window.
Effective routes for a NIC
If you want to get even more granular, you can create custom inbound or outbound rules in your NSGs with the appropriate tags for what networks you want to allow or block. Here you can see my choices for an outbound rule where I can pick not only Azure Storage but also which region(s) I want to allow.
NSG firewall rule with tags
By default when you create a storage account, it has public access. To change this and only allow connectivity from your choice of locations, including a vNet, follow these instructions. Where availability zones are available, they'll spread the storage service endpoints across zones.
For Azure SQL, follow these instructions. Additional services are likely to show up in Service endpoints in the future.
Services and application security groups
What if you use another Azure PaaS service and you don't want it to have public access either? As Microsoft also announced at Ignite, they now offer the ability to connect services directly into your vNet, allowing access to them from within your vNet. Currently supported are the following:
- Service fabric
- Virtual machine scale sets
- HDInsight
- App Service Environment
- RedisCache
- API Management
- Application Gateway (internal)
- Azure Active Directory Domain Services
- Azure Batch
In most cases, these services will deploy an internal load balancer when you connect them to a vNet.
Also announced at Ignite were ASGs—a way to logically group VM resources together and use custom names to refer to them in NSG rules. Still in preview, this feature allows you to define tags (called WebServers, AppServers, and DatabaseServers for example) and then create rules around which ports and networks these resources can communicate with. Note that all resources must be in the same vNet, but they can be in different subnets.
Application security groups (image credit Microsoft)
The options for securing your Azure resources and networks are increasing. The key is knowing about them when planning or enhancing your cloud deployments, and we at 4sysops are here to help you.
Subscribe to 4sysops newsletter!
In my next post I will give an overview of the new features in Azure networking.
Thanks Paul, good and clear explination of the concept service endpoint.