A few days ago, our last post dealt with the Azure Service Endpoint feature, which allows you not to expose your Azure resources to the Internet, for obvious security reasons.
Today we are going to see another solution present in Azure, which makes it possible to further restrict the exposure of services, thanks to Azure Private Link.
Unlike Azure Service Endpoint functionality, where the endpoint is a category of an Azure service, such as Storage, SQL Database, or Key Vault; Azure Private Link, offers an endpoint that points to a service deployed by the user:
To return to Azure Private Link, this feature brings together several concepts:
- Private Endpoint : Which is your private endpoint with a network interface that uses a private IP address from your virtual network
- Private Link Resource : Which is the target service you want to consume via its private addressing.
- Private Link : This is the association between your private endpoint and your target service.
- Private Link Service : This is what maps a service that is in another VNET behind an Azure Load Balancer Standard.
Use case 1:
Our first use case is to consume a storage account, and more specifically a blob object, through the Azure private network (Microsoft Backbone) with Azure Private Link.
To do this, we deployed the following Azure resources:
- Storage Account – SA (PaaS Service which will be taken as an example)
- Virtual Machine – VM
- Security Group – NSG
- Public IP address
- Network Interface – NIC
- Hard disk – Disk
- Virtual Network – VNET / Subnet
1. PaaS service exposed on the Internet
For our first example, our storage account will have no limitation, and will therefore be exposed on the Internet:
(This is obviously not to be reproduced for obvious security reasons, but it helps to better understand the Service Endpoint mechanism) .
If we do a test from our machine, we access our file stored on the SA, without any problem:
Let's look at our diagram which explains how our SA will be consumed, by our VM, and potentially by other services or external users:
When our VM wishes to connect or consume an Azure service, by default, the network flow goes out on the Internet to then arrive on the service concerned, through its public endpoint (DNS), in our case https://saprivatedemo01. blob.core.windows.net/demo/file.txt
Now let's see what it looks like with Azure Private Link.
2. Enable Azure Private Link
Setting up Azure Private Link is not complicated, just follow a few steps:
- First step, by clicking on Private Endpoint at the SA level:
- Next, we define the basic information:
- Then we choose the resource we want to consume, in our case it is a blob file:
- It is at this stage that we will select the VNET and Subnet in which the network interface will be created, i.e. the private IP of our Private Endpoint:
(We do not activate the Network option policy for private endpoints which allows the use of UDRs and NSGs in our example, and we choose a dynamic IP within the subnet). - We finish by integrating our Private Endpoint into an Azure DNS private zone, which in this case will be privatelink.blob.core.windows.net : (Obviously you could use an existing Azure DNS private zone or your own DNS server).
I can now retrieve the private endpoint saprivatedemo01.privatelink.blob.core.windows.net which I will be able to use instead of saprivatedemo01.blob.core.windows.net
While we're at it, we're disabling public access on our SA so that it's no longer exposed on the Internet, which gives us the following configuration:
Now let's test from our VM01 that it works correctly through the Azure DNS private zone:
A new look at our diagram:
We now see that the network flow of the VM no longer goes through the Internet, but directly via Private Endpoint
And of course internet traffic is blocked since I disabled it.
But how does it work in practice?
As we have seen, when you create a Private Endpoint, you create a private IP within a subnet, and therefore within the VNET.
But that's not all !
As we can see in the image below, a private DNS CNAME entry is created on the DNS server which manages the saprivatedemo01.blob.core.windows.net zone and which points to the Azure private DNS zone we have created namely privatelink.blob.core.windows.net
Use case 2:
In this second use case, we want to consume a web service hosted on a VM02 deployed in another VNET02 which has the same address as our first VNET01.
Thus this configuration makes it impossible to set up a VNET Peering between the 2 VNETs because of the overlap (overlapping) of the IP addresses of the VNETs.
This is where Private Link Service comes in.
As we mentioned earlier, we will be able to consume our service, our VM02, through an Azure Load Balancer Standard.
We therefore start by creating an internal LB, ie with a private address, namely LB01, in the VNET02 where our VM02 is stored .
- Let's fill in the basic information:
- We select the VNET02, letting Azure define its private IP address:
- Then we define the endpoint on which the traffic will be sent when we arrive on LB01, which will therefore be our VM02:
- The next step allows you to define a rule that will associate the endpoint with the listening port of LB01, as well as the port on which to send traffic to VM02.
We also take the opportunity to create a probe that will check the integrity of the service on the VM02 side : - The following configuration steps are not necessary, so you can click on review and create to create the LB.
Here is the result after a few seconds:
Now that we have created our LB01, let's move on to the next step which is the creation of our Private Link Service.
In the search bar of the Azure portal, we search for Private Link, we arrive at the Private Link Center service.
We just need to click on Create Private Link Service:
- Let's start by filling in the information:
- The next step is important because this is where we will select our LB01, as well as the associated configuration:
- Then we define, the accesses which allow to consume the Private Link Service:
(We limit the access to our subscription, but it is obviously possible to limit only the use to a service, as with our VM01).
We can then directly click on review and create to create our Private Link Service.
Now that LB01 and the Private Link Service are created, let's move on to the last step, which is the creation of our Private Endpoint.
There are two possibilities, the first, returning to the Private Link Center service, the second, going to the Private Link Service that we have just created. For my part, I choose the second option.
- At the level of my PrivateLinkService01, I will now create my Private Endpoint:
On the Resource tab we have nothing to configure, but why?
Simply because when creating the Private Link Service we had selected the Auto-approve option , and since we only have one Private Link Service within this subscription, it is selected by default:
- Then we select the VNET in which to deploy our Private Endpoint, so it's the same one where our VM01 is hosted , ie VNET01. We leave the IP allocation method to dynamic:
- To date, the DNS option is not supported for a Private Endpoint connected to a Private Link Service , so I will connect through its private IP.
We can then directly click on review and create to create our Private Endpoint: - I retrieve the IP of the newly created Private Endpoint:
- All that remains is to test access to my VM02 from my VM01 via the combination of the Private Link Service and the Private Endpoint, which is completely transparent to the user.
Everything works as expected:
A last look at our diagram shows that we are able to consume the service hosted on VM02 which has the same network addressing as our VM01 , thanks to our internal LB:
At the time of writing these few lines, here is the list of Azure services that are currently supported:
- Azure API Management – General Availability
- Azure App Configuration – General Availability
- Azure Automation – General Availability
- Azure Backup – General Availability
- Azure Batch (batchAccount) – General Availability
- Azure Batch (nodeManagement) – Preview
- Azure Bot Service – General Availability
- Azure Cache for Redis – General Availability
- Azure Cognitive Services – General Availability
- Azure Container Registry – General Availability
- Azure Cosmos DB – General Availability
- Azure Data Factory – General Availability
- Azure Database for MariaDB – General Availability
- Azure Database for MySQL – General Availability
- Azure Database for PostgreSQL – Single server – General Availability
- Azure Digital Twins – Preview
- Azure Event Grid – General Availability
- Azure Event Hub – General Availability
- Azure File Sync – General Availability
- Azure Files – General Availability
- Azure HDInsight – General Availability
- Azure IoT Hub – General Availability
- Azure Key Vault – General Availability
- Azure Kubernetes Service – Kubernetes API – General Availability
- Azure Machine Learning – General Availability
- Azure Managed Disks – General Availability
- Azure Migrate – General Availability
- Azure Monitor (Log Analytics & Application Insights) – General Availability
- Azure Queue storage – General Availability
- Azure Relay – Preview
- Azure Search – General Availability
- Azure Service Bus – General Availability
- Azure SignalR – General Availability
- Azure SQL Database – General Availability
- Azure Static Web Apps - Preview
- Azure Synapse Analytics – General Availability
- Azure Table storage – General Availability
- Azure Web Apps – General Availability
- Microsoft Purview – General Availability
The list of services can be viewed here: https://docs.microsoft.com/en-us/azure/private-link/availability
To sum up, Private Link is an excellent solution for not exposing its PaaS services on the Internet.
Today all the services are not yet supported, but the list evolves very regularly.
Microsoft encourages the use of Private Link for obvious security reasons, but also to reduce latency by going through the Microsoft backbone, instead of using the Internet.