Earlier this week, a new capability called “Azure Private Link” (and also “Azure Private Endpoint”) went into public preview. As a nice copy & past from the documentation page ;
Azure Private Link enables you to access Azure PaaS Services (for example, Azure Storage and SQL Database) and Azure hosted customer/partner services over a Private Endpoint in your virtual network. Traffic between your virtual network and the service traverses over the Microsoft backbone network, eliminating exposure from the public Internet. You can also create your own Private Link Service in your virtual network (VNet) and deliver it privately to your customers. The setup and consumption experience using Azure Private Link is consistent across Azure PaaS, customer-owned, and shared partner services.
As always, we’ll take this one out for a spin! For this we’ll see if we can access a storage account privately (from a virtual machine) over the VNET.
Note : Preview Availability
First thing, do note that Private Link & Private Endpoint are currently (at the time of writing) in preview. This has an impact on the regional availability! Check out the docs to see which regions are currently supported!
For instance, when I was testing, “West Europe” was not supported. Which caused the following error!
Let’s create our storage account, where we select one of the supported regions (West Us in the example) ;
Where on the networking pane, we’ll select “Private endpoint” ;
Here we can configure the “Private Endpoint” ;
Do note the private DNS integration (on which we’ll come back later) and that we link a specific storage service to a specific subnet (the subnet’s private IP = Private Endpoint). So let’s create the storage account ;
Once created, you can see that the configuration section now has an “Private endpoint connection” option ;
Let’s take a look at the firewall configuration, and we can see that everything is locked down.
Let’s try to validate this by browsing to the storage account via the Storage Explorer (from my internet connected workstation) ;
And that does not work! (which is a good thing, as it validates the premise of it being locked down from externally). Same thing applies to the portal view too by the way ;
Now let’s create a VM inside of the VNET ;
Now let’s create a SAS token…
And use it with azcopy, which is running from the VM inside of our VNET ;
And that works! Let’s download the file again and do a diff ;
No tricks done! Same file! 😉
Under the hood
Let’s do an nslookup from that VM ;
We can notice that the DNS query is “intercepted” via the private DNS. So that’s the “secret sauce” in this setup it seems.
With service endpoints we already had a way to privately access PaaS services (like Azure Storage) from a VNET. Though service endpoints still relied on the public IP of the PaaS service. With private link/endpoint, you can now provide the PaaS services with a private IP from within that VNET. Where in the security world, this will have a whole different perception.