For this article, in keeping with my #AzureNetworking series, I thought it would be a nice simple idea to walk through the mechanics of the ‘Azure Private Link’.

Typically in Azure, when it comes to PaaS services, it is now supported for a number of PaaS services to configure access via a Private VNET/Subnet only, this is known as ‘Private Endpoint‘ or even your own architected solutions behind load balancers can remain on a private network which is known as ‘Private Link Service‘ and have no exposure to the outside world via a public IP directly.

We will just discuss the ability to create a Private Endpoint in this article.

Private Link gives us the ability to only expose access to our resources via the private network only which is obviously great from a security perspective when it comes to accessing resources that before Private Link would typically be accessed via a public URI with a shared secret etc. Private Link brings the ability to bring access control back down to the network layer and exposes the resource to a private IP on a VNET of your choosing.

Create Resource you want to access

There are a few ways to create a private endpoint, either on its own, or as we create a new resource such as a storage account. For the purposes of this demonstration I have already created a storage account ‘jonnychipzsa’ with its networking configured for ‘Private Endpoint’

Create Private Endpoint

So as long as we have a resource we want to configure access to, the next thing we need to create is a ‘Private Endpoint’. This is fundamentally a network interface that is configured on a VNET of your choice and exposes a resource of your choosing to your VNET over a Private IP.

The current list of resources available to be exposed via Private Link can be found here. But as per our example, we will configure this Private Endpoint to reference the Storage Account I have created.

Basic Configuration:

Resource Configuration:

Within the resource configuration section, we can specify the location of our storage account, and we have the ability to target a sub-resource. What this means in the context of a storage account, is that we can target a blob, table, queue, file, web or dfs for exposure to our private end point. We will chose ‘file’ as our targeted endpoint for private link.

VNet / Private DNS Zone Configuration:

The next step is to select which VNET/Subnet combination you would like to expose your resource with a private IP. For the purposes of this demo, I have a server sat in a 172.16.1.0/24 subnet, and I have another unused subnet named ‘Default’ that I think I will use to host my Private endpoints (172.16.0.0/24 subnet). Of course depending on your application, this subnet could be designed with your full considerations and restrictions made to/from via NSG’s or firewalls etc. But we will keep this simple for the purposes of this set up.

The other element we will configure here is whether or not we want to integrate the configuration with a Private DNS zone to enable our clients to be able to access the resources via a host name. Therefore we will say ‘yes’ and allow a new private DNS zone of ‘privatelink.file.core.windows.net’ to be configured.

Tagging:

Its always good practice to have your resources tagged in a way that works for your business.

We can now click on Create to allow Azure to create our Private Endpoint.

Just one point to pick up on here with regards to the created DNS entry for our storage account ‘jonnychipzsa’ as can be seen, these DNS entries are actually internet ‘resolvable’ however what we will see is that the DNS entry in Public DNS is actually a CNAME entry pointing at the host name of our ‘Private’ DNS zone which is NOT resolvable externally to our VNET. For me information on this configuration read this MS docs article.

Testing access

Ok so, I have created one file share in our ‘jonnychipzsa’ storage account as follows:

If I were to now jump onto my ‘VM01’ machine that is sat in the same VNET as our Private Endpoint has been configured I can see if I can resolve the url to the Storage account:

Here we can see that the ‘Public’ URL provides a CNAME response to our ‘Private’ DNS Zone which in turn shows our endpoint has picked up an IP from our ‘default’ subnet of 172.16.0.4.

In order to access this File Share without setting up kerberos based authentication, I will use Azure Storage Explorer and the connection string to the storage account. Once populated and created I can now access my File share over my Private IP!!!

So as you can see, there are lots of applications for Private Link and some great security benefits!

I do hope you have found this article useful, please comment and share your own stories with Private Link, there is some great potential with this solution in Azure! Remember that this article has only described the use of Azure Private Link – Endpoint, there is an ability to create access to your own solutions in Azure using Private Link – Service as well.

Thanks for reading!

More info:

https://azure.microsoft.com/en-us/services/private-link/

https://docs.microsoft.com/en-gb/azure/private-link/