Azure Private Link is a technology designed to provide private connectivity to selected PaaS services, customer-owned and partner offered services.
Private Link allows you to access services over a private endpoint deployed into your virtual network. All traffic privately traverses the Microsoft global backbone, eliminating any exposure to the public internet and increasing security.
With no need for additional network resources such as gateways, NAT devices and public IP address network complexity is also reduced.
There are two key components of Azure Private Link:
- Private Endpoint – a network interface connected to your virtual network, assigned with a private IP address. It is used to connect privately and securely to a service powered by Azure Private Link or a Private Link Service that you or a partner might own.
- Private Link Service – your own service, powered by Azure Private Link that runs behind an Azure Standard Load Balancer, enabled for Private Link access. This service can be privately connected with and consumed using Private Endpoints deployed in the consumer’s virtual network.
Benefits of Private Link
- The service can be used to connect virtual networks with overlapping address spaces
- Secures access to services over the Microsoft backbone
- Allows private access to services running in Azure from on-premise or peered networks
- The service can connect to resources running in other regions offering global reach
- Ability to enable private link access to your services
- Supports various PaaS, partner and customer-owned services
An up to date list of services that support Private Link and region availability can be found here.
How do Private Endpoints differ to Service Endpoints?
One key difference between the technologies is that although a Service Endpoint can be restricted to only accept access from a specific virtual network, it is still accessed over a public endpoint. This is in contrast to a Private Endpoint which is created with a private IP.
Service endpoints are also only locked down to a specific service, not a specific resource. Whereas with Private Link, the private endpoint allows more granular access to the specific sub-resource.
Creating a Private Endpoint
Private Link Center is the management tool used for creating and managing Private endpoints and Private link services. In the search bar at the top of the Azure portal type private link, then select the service from the dropdown menu.
To begin creating a private endpoint, select Private endpoints from the left menu. Then from the top ribbon click + Add to open the Create a private endpoint wizard.
The first thing we need to do is name the endpoint instance and define where it is to be created. Not only geographically in terms of the region but also in which subscription and resource group.
Now we need to define which resource and sub-resource the private endpoint allows access. Selecting a resource in your own directory is done using drop-down menus. Initiating a connection request to a resource in another tenancy is achieved using the resource ID or alias.
In this example, we are configuring the Private Endpoint to provide access to Blob storage. File Shares, Queues or Tables will not inherit the same access permissions. This enables us to be prescriptive and secure resources to a level not possible using Service Endpoints.
The next step is to configure the virtual network and subnet where the endpoint will be deployed.
It is also advised that a private DNS record is created and used when accessing the service via the endpoint. This can either be hosted by your own DNS solution or integrated with an Azure private DNS zone.
To make testing in this example easier, we will choose to integrate with an Azure private DNS zone.
The penultimate step is to define any tags before clicking Review + Create.
Assuming that validation passes successful, the final step is for us to click on Create to kick off the deployment process.
Browsing to the newly created endpoint, we can see from the overview page details such as its network interface, the virtual network and subnet its connected, FQDN and assigned private IP address (10.0.0.5).
Jumping to the storage account the endpoint was linked with and expand the Firewall and virtual network tab. We see that the only access allowed is for trusted Microsft services.
Switching to the Private endpoint connections tab, we should be able to see listed the private endpoint that’s just been created. If configured correctly, the connection state should appear as Approved.
Now everything has been configured, we can go ahead and test access to the storage account is only allowed through our private endpoint.
From a virtual machine connected to the same virtual network, open a PowerShell console and enter nslookup dns.name.of.private.endpoint. The command-line utility outputs DNS details including the IP address registered with the DNS name. In our example, the IP address output matches the private address assigned to our endpoint.
Another way to test the endpoint is working as expected is by using Azure Storage Explorer that can be downloaded here.
Open Azure Storage Explorer, right-click Storage Accounts and then select Connect to Azure storage from the popup menu. Enter the connection string that can be copied from the Access Key blade of the storage account and then click on Connect.
We now have access to blob containers and the ability to create, browse, edit and delete.
When associating a resource and sub-resources to the endpoint, we selected Blob within the storage account. Due to the increased granularity that Private Endpoints offer when attempting to browses File Shares, Queues or Tables, access fails as expected.
For completeness, let’s run Azure Storage Explorer on a machine that’s not connected to the same virtual network. Now when attempting to connect to the storage account, this action fails with the following error message.
To learn more about Azure Private Link, head over to Microsoft docs: https://docs.microsoft.com/en-gb/azure/private-link/
