Azure networking team just introduced preview of Azure Private Link (https://azure.microsoft.com/en-us/blog/announcing-azure-private-link/). It promises to bring functionality previously unavailable for bridging gap in networking between PaaS and VNETs as well as between VNETs in different tenants/subscriptions.
There are 2 distinctive use cases for Private Link:
- Private Link for accessing Azure PaaS Services
- Private Link to Private Link Service connection for connectivity across tenants and subscriptions and even overlapping IP address across VNETs
Private Link for accessing Azure PaaS Services
Traditionally if you wanted to access PaaS services securely within VNET you’d need enable
VNET service endpoint which will in turn enable routing of requests from within your VNET directly to your PaaS service. PaaS will see your requests coming from private IP range of your VNET as opposed public IP address before the enablement. You still go through public IP of PaaS service though as a result, just not route through edge.
Private Link solution creates endpoint with local IP address on your subnet through which you can access your PaaS service. You will in fact see Network Interface resource being created with associated IP address once your enable this resource.
It will be similar to reverse NAT from networking point of view.
Example is below where I created storage account called
privatelinkMSDN which does not have integration into VNETs so by default it will deny all connections to blobs externally or internally.
Accessing blob externally will produce HTTP error as expected due to IP filtering on storage account.
Trying to resolve name externally produces external IP address of service
PS C:\Users\174181> resolve-dnsname privatelinkmsdn.privatelink.blob.core.windows.net -Type A Name Type TTL Section NameHost ---- ---- --- ------- -------- privatelinkmsdn.privatelink.blob.core.windows.net CNAME 53 Answer blob.bl5prdstr09a.store.core.windows.net Name : blob.bl5prdstr09a.store.core.windows.net QueryType : A TTL : 52 Section : Answer IP4Address : 220.127.116.11
Creating of Private Endpoint is not covered here since it’s well documented at Microsoft. End result is shown below. Following resources are created as result of creation of Private Endpoint:
- DNS zone named as
privatelink.blob.core.windows.netwith record pointing to your Private Endpoint
- Private Endpoint itself
- Network Interface resource associated with Private Endpoint
- Private IP address associated with Network Interface
While externally this URL resolves to external IP address, resolving the same name within VNET delegates resolution to private DNS zone and provides internet IP address of NIC card and hence provides access to image in blob as expected.
PS C:\Users\cloudadmin> resolve-dnsname privatelinkmsdn.privatelink.blob.core.windows.net -Type A Name Type TTL Section IPAddress ---- ---- --- ------- --------- privatelinkmsdn.privatelink.blob.core.windows. A 1800 Answer 10.1.0.4
Private Link Service connection
Initial Configuration I’m working with is described below
- Azure Tenant 1 (suvalian.com) which is associated with Subscription 2. This will be hypothetical ISV customer which provides services to tenant 2 below (like VDI for example). Subscription 1 contains VNET called MSDN-VNET with 10.1.0.0/16 address space.
- Azure tenant 2 (nttdata.com) which is associated with Subscription 2. This is customer who would like to privately connect to your services. Subscription 2 contains VNET called NTT-VNET with 10.1.0.0/16 address space (please note it’s the same address space as VNET in Subscription 1)
There is no trust between 2 tenants (that is there no guest accounts in either directory from other directory), so essentially it’s completely separate Azure Environments.
Traditionally to connect from Azure 2 to Azure 1 you’d have to either:
- Expose your services via public IP address with restrictive NSG rules on it (poor security and additional cost due to ingress traffic charges)
- Create VNET to VNET connectivity via VPN gateway (costly, can not have overlapped IP address space, cumbersome to setup and administer)
- Create VNET peering between VNETS (can not have overlapped IP address space)
Solution consists of parts depicted on image below:
In Subsription 2 you create:
- Private Link Service (PLS) which will be used as endpoint connection target for your customers
- Network Interface resource with IP addresses which will be used for NAT (10.1.2.5)
- Standard Load balancer with load balancing rule
- Backend pool with IIS (10.1.1.4) which you want to provide access to your customer
In Subscription 1 you create
- Private Endpoint which will connect to PLS in Subscription 2
- Network Interface with IP (10.1.0.4) which will be used for connectivity to PLS
Client 1 living in Subscription 1 can connect to IIS resource in Subscription 2 via IP of 10.1.0.4. IIS is configured to respond with information about client connecting to it. Opening web page on 10.1.0.4 serves page from IIS web server identifying that HTTP connection originates from 10.1.2.5
PS C:\Users\cloudadmin> (Invoke-WebRequest http://10.1.0.4/).Content REMOTE_ADDR 10.1.2.5