Sep 09 2022 06:33 AM - edited Sep 12 2022 09:53 PM
Sep 09 2022 06:33 AM - edited Sep 12 2022 09:53 PM
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:
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:
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.
Setting up Azure Private Link is not complicated, just follow a few steps:
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
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 .
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:
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.
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:
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:
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.