Let’s dive into a new feature in Azure virtual networking: the Azure private subnet. It’s more than just a feature, it’s a strategic approach to enhancing network security and management.
Albeit, in our opinion, a few years late.
Note: AWS has always required customers to provide explicit outbound connectivity.
Why Restricting Default Outbound Internet Access is Crucial
A key aspect of network security in cloud environments is controlling and restricting default outbound internet access. Unrestricted access can open the door to potential security vulnerabilities, such as data exfiltration or unauthorised external communications. By limiting this access, organisations can better protect sensitive data and maintain a tighter security posture. This control is particularly vital in environments where regulatory compliance and data privacy are paramount. Managing outbound access is not just about controlling where data can go, it’s about safeguarding the integrity and security of the entire network ecosystem.
Azure’s Private Subnet: A Closer Inspection
Creating a private subnet in Azure is about setting boundaries for your virtual machines (VMs). It’s like putting up a “Do not enter” or rather “Do not leave” sign for unauthorised internet access (egress). While creating a private subnet is very easy via PowerShell, ARM/bicep or Azure CLI, identifying a private subnet isn’t straightforward at time of writing. While eventually this will become the default, it currently isn’t, and it should be easier to identify those subnets.
After we created a private subnet we first went to the subnet blade in the Azure Portal, but alas, that was not very helpful. The only ways currently to identify private subnets is via the JSON blade on the vnet (make sure you change the API version from what it selects by default to the very latest) or via Azure CLI.
az network vnet subnet list -g <rgName> --vnet-name <vnetName>
This will give you output similar to the below.
Note: “defaultOutboundAccess: false”.
We then checked the “Effective Routes” on a Network Interface of a VM deployed into a private subnet. We expected those to show no internet route, but you’d be excused to think that this is a subnet with internet access. After all, the NIC does know a route out to the internet.
So, unfortunately, currently VMs won’t know that they don’t have internet access. Administrators will only be able to detect those subnets via CLI, PowerShell, or manually
Moving Forward: Balancing Security and Clarity in Azure
The private subnet feature is a welcome addition to the virtual network service. We hope Microsoft will make it easier for network and security administrators to identify private subnets. Maybe just do it via routes? If no internet access is available, don’t show a route to the internet. Just an idea.
One last call-out: Please don’t just go and put public IPs on every VM so you get internet access, because that will also make the VM accessible FROM the internet, and most likely that is not the desired effect.