Azure Private Link (preview) – What is it? Why use it?
Microsoft recently announced Azure Private Link as a preview available initially across 6 regions in the US (East/South Central/North Central/West Central/West and West US 2). I’m going to drill into what Private Link is and why you might want to use it.
What is it?
First off what is Private Link? Well there are actually 2 different elements that make up Private Link.
- Private Endpoint
- Private Link Service
I’m going to touch on Private Endpoint in this post and will then follow up with a post on Private Link Service as the Private Endpoint is substantial topic on its own.
Private Endpoint
What is Private Endpoint? In a nutshell it’s a means to connect to Azure Services over a private IP. Typically the services its aimed at working with would be available over a public IP only, for example, Azure SQL. In a standard deployment when you create an Azure SQL instance it is given a public IP and public DNS name and your clients will connect the DNS name which ultimately points to public IP as the endpoint. With Private Link you can create a Private Link Endpoint on the subnet of your choosing and link this to your Azure SQL instance.
You can think of a Private Endpoint much like a NIC on a Virtual Machine, it gets an IP on the subnet you associate it with and you can register a DNS name to it. In the Azure SQL example above, instead of having your clients connect using the public DNS name, you’d instead register an A record in your own DNS zone, registering it against the private IP and have clients connect using your DNS name and ultimately connecting to your SQL instance using the private IP.
Now my explanation above is very simplistic and while I’ve referenced a NIC, a Private Endpoint is a top level resource in Azure, so there are differences between the too.
Why use it?
Ok, so why would you want to use a Private Endpoint? What does it give you that you didn’t have previously?
Primary Use Case?
For me, the primary use case for a Private Endpoint is allowing on-prem connectivity to Azure services (that leverage a public IP to expose the service) over a private IP. Previously if you wanted to connect to an Azure SQL instance from on-prem you had 2 options, you could connect over the internet or if you had Express Route you could leverage Microsoft peering to connect over your Express Route. This was not ideal from a security perspective and could be a pain to setup. Connectivity for Microsoft peering tended to map back to public IPs on your Express Route circuit which meant permitting a single host to connect to something in the cloud was difficult if not impossible.
For services like Azure storage on-prem connectivity was even more of a challenge, while your Azure SQL IP is unlikely to change over time there is no guarantee that your Storage Account would always have the same IP. So typically granting access to a Storage Account from on-prem meant you needed to permit outbound connectivity to all the known IPs for storage in a given region. Permitting this at an edge firewall would open a wide range of IPs which is far from ideal for security. Think of data leakage, you might be permitting access to your storage accounts but equally permitting lots of others too.
With Private Endpoint I can create a DNS entry pointing to an IP in a subnet within my Vnet, connect it to my storage account and connect to that from on-prem over my Site to Site VPN or Express Route. On the on-prem side I only need to permit connections to that single destination IP. I’m not exposing other storage accounts as i would with a public IP range and i’m ensuring my traffic doesn’t route over the internet also.
In the on-prem to cloud scenario Private Endpoints will allow you to publish services to specific subnets, which if you tier your networks can help from a security standpoint, for example, you could define a data subnet that all of your Private Endpoints for SQL will live within. Once setup you will know from a traffic profile perspective that you shouldn’t see any network flows for SQL that don’t flow into this subnet. This is a simplistic example but makes my point.
Other Use Cases…
The on-prem to Azure service isn’t the only use case for a Private Endpoint. Deployments within Azure can leverage Private Endpoints too, so again in the SQL or Storage Account example, you can have your Azure VM connect to the service via the private IP. In this scenario you could use an outbound rules on your NSG for your VM to restrict access to the private IP. While Service Endpoints provide a means to connect privately you can’t restrict access to a specific instance of service in an NSG, i.e. you permit SQL in a region.
Private Endpoints can also be used to consume instances of the Private Link Service, I’ll go into more detail in Part 2 but I can see some interesting scenarios where you could create a Private Endpoint that connects to a Private Link Service in another subscription, be that your own or a partners or vendors. For example you could stand up services in a central subscription and then consume them via Private Endpoints in your edge subscriptions without needing to expose anything else in either subscription.
What is missing?
So there are few things that Private Endpoints don’t support and I’m going to call these out as they may impact you and your decision to leverage them. First of all Private Link is in preview so some of what is missing now will likely be added over time.
NSG aren’t supported on a Private Endpoint, while subnets containing a Private Endpoint can have NSG associated with it, the rules will not be effective on traffic processed by the Private Endpoint. This for me is quite a big drawback, it removes a layer of control around who can and can’t access your Private Endpoint. In the on-prem to cloud scenario you’re going to need a firewall between your on-prem environment and the Private Endpoint to control access. Within Azure itself you’re going to be reliant on outbound NSG rules on your resources and if you don’t operate deny by default (you should) you’ll not easily implement this.
Private Endpoint won’t work on subnets with Service Endpoints enabled. This isn’t a big one but if you’ve invested in Service Endpoint as a pattern for consuming services you’ll need to create some new subnets to support your Private Endpoints.
Currently Private Endpoint doesn’t support multi-region deployments where your Private Endpoint and the Private Link Service are deployed in different regions but this will come down the line.
Some services which you’ve deployed into your vnet cannot consume Private Endpoints during the preview, App Service Plan, Azure Container Instance, Azure NetApp Files and Azure Dedicated HSM.
Private Link is currently available in Preview, more information is available here: (https://docs.microsoft.com/en-gb/azure/private-link/).
