Azure Private Link Services

After knowing a little more how Azure Kubernetes Service works with Azure Private Link, I could not help but wonder how other Azure Platform-as-a-Service (PaaS) integrates with Azure Private Link. Luckily, it was an easy search on the Net to find official documentation around this topic.

In this article, it provides the example of integrating Azure Key Vault (AKV) to Azure Private Link. Before jumping into the actual step-by-step explanation, a little clarification around these technical terms would be helpful.

Image credit: Microsoft official documentation

A little more explanation why Azure Private Link Service (APLS) is not shown after deploying some Azure PaaS with Private Link, such as Azure Container Registry (ACR) or the control plane of Azure Kubernetes Service (AKS). It is because these Azure PaaS could only use Microsoft-managed APLS instead of self-managed APLS. For more information, please check this section of the article.

Just like the article mentions, a key vault, an azure virtual network (VNET) and subnet of the VNET need to be created. Please ensure the operator has at least contributor permission over the key vault and VNET. Another thing to pay attention is that Azure PaaS that would like to use Azure private endpoints do NOT need to be in the same region as VNET. However, the Azure private endpoints associated with these Azure PaaS would be in the same region as VNET.

After all, the main purpose of having APLS is to have resources located in one specific region to communicate with Azure PaaS located elsewhere over a private IP address (services communicate with each other over Microsoft backbone).

First, provision a VNET in the desired location (for most users considering APLS, they must already have plenty of resource located in the target VNET). Mine is located in West US 2.

Next, a STANDARD load balancer (SLB) is required. Since the VNET I provisioned located in West US 2, the standard load balancer would be provisioned in West US 2 as well.

The SLB is used for network address translation (NAT), so when resources located in this VNET trying to contact Azure PaaS exposed with private endpoint (a private IP address in this VNET essentially), the private IP addresses would be source NAT (SNAT) to their public IP addresses.

Then, provision a key vault in any region. Mine is provisioned in East US 2.

The private endpoint could be provisioned when creating the key vault or after the creation in Networking tab — Private endpoint connections.

At last, it is the time of truth. For testing purpose, I provision a Ubuntu 18.04 VM in this VNET and SSH into the terminal. Based on this section of the article, AKV’s fully qualified domain name (FQDN) would be resolved to private IP address in this VNET. Mine works out as expected.

When I checked the connected devices in VNET, I could see a private endpoint associated network interface (NIC) has been provisioned.

At this point, any resource located in this VNET should be able to communicate with this AKV with private endpoint without exposing any traffic over Internet. Hence, fulfilling the main purpose of using APLS in any environment in the first place.

There might be things I explain incorrectly in this article, please feel free to let me know in the responses below. Thank you!

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jonathan

Learning new things about Kubernetes every day. Hopefully, the learning notes could help people on the same journey!