Azure Private Endpoint

Azure Private Link is an Azure service that enables customers to access supported Azure PaaS Services (Azure SQL & Storage etc..) over a private endpoint in an Azure Virtual Network. This ensures the network traffic between virtual network and service travels via the Microsoft backbone within your network boundary, including from on-premises when connectivity such as ExpressRoute is configured.

Allowing services to be addressable via a private IP address allows public IP addresses and therefore internet traffic to be blocked.

It is also possible to create a Private Link Service in your virtual network and deliver it privately to your customers.

Architecture

A private endpoint is a network interface in a virtual network for securely connecting a service powered by Azure Private Link.  A private endpoint uses a private IP address from the selected VNet, make it addressable from that VNet and any peered VNet.

When configured, Azure will create a Canonical name (CNAME) DNS record for the public DNS in a private DNS zone to re-direct it to the private domain name (private endpoint). When an application tries to resolve a service with a name, it will be resolved to private endpoints instead of the public DNS namespace.  Please note: outside of the DNS zone, the FQDN for the service will continue to resolve to the services public endpoint. Adding a Private Link to a service does not automatically remove access from the public endpoint you will still need to block that access using the services firewall settings.

Why is it needed?

This service is required for connecting Azure PaaS service with your azure resource, by private connectivity and not exposing to the internet. This removes NSG rules or firewall rules connectivity requirements for the Azure Services.

This service provides data exfiltration protection by default, which means private endpoint maps the specific service and not the entire service. For example, a storage account, a private endpoint can be a blob, or file, or queue.

Compare Private endpoint and Service endpoint:

The below table provides the comparison Azure service Endpoint and Private Endpoint:

Service Endpoint	Private link- Private Endpoint
The traffic flows from Azure VNet to Azure PaaS service is being accessed on its public address via Microsoft backbone.	The traffic flows from Azure VNet to Azure PaaS service is being accessed on its private address via Microsoft backbone within your network.
Traffic to the PaaS resource leaves VNet and goes on public IP.	Traffic to the PaaS resource does not leave the VNet. Since the endpoint attached to VNet with a private IP address.
Need to have NVA / Firewall for data exfiltration.	Built-in data exfiltration.
Simple and Easy to setup.	Slightly complex to set up, due to private DNS configuration.

Technical explanation:

I will assume you are familiar with deploying virtual machines, virtual networks, and SQL PaaS in Azure and will not cover these steps below. However, If you require assistance, please refer to the following links:

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/quick-create-portal

https://docs.microsoft.com/en-us/azure/virtual-network/quick-create-portal

https://docs.microsoft.com/en-us/azure/azure-sql/database/single-database-create-quickstart?tabs=azure-portal

I will walk you through the options of connecting to an Azure PaaS service from the virtual network, covering the pros and cons of each approach.

With this setup we have below resources:

• Azure VNET with one subnet and one Azure VM in the subnet.
• Azure SQL PaaS

Method #1: Not using either Service Endpoint or Private Endpoint:

Consider application consisting of a Virtual Machine hosted in your virtual network and a SQL PaaS instance.

When not using either the service endpoint or private endpoint approach the traffic from VM to SQL DB connection will occur via the public endpoint (xxxx.database.windows.net) of the SQL database and network traffic flow out via the internet.

When SQL DB will receive the request from VM, it will not see a private IP address VM (Technically the traffic does not go out when resources are in the same region). This will not provide an option to whitelist the IP address of VM in the SQL firewall. This has a major security risk and many organizations will not allow this traffic. Security has a scope for improvement.

Log into a VM and run below PowerShell command to verify SQL connection from VM (substituting the name of your database):

Test-NetConnection -ComputerName az-sql-server01.database.windows.net -Port 1433

Results:

---

let’s check network routes, click on Network interface of Virtual machine and click effective routes:

Discussion point: SQL PaaS server is resolved to its public IP address and it shows connection happens via public IP address and security point is compromised.  This proves the traffic flows from VM to SQL are via the internet, of Microsoft Azure backbone. Since Azure VM will have internet access by default.

Method #2: Enable Service Endpoint:

Now on the same setup, let’s enable Service endpoints for SQL PaaS service. Follow the below steps:

1. Click on the SQL server and select firewalls and virtual networks under security.
2. Under the Virtual network section, click + Add an existing virtual network.
3. Provide below information for settings and click Ok.

• Name: SQL-service
• Subscription: Select your subscription
• Virtual network: select the virtual network, where VM is running.
• Subnet: Select the subnet of VM is created and running.

4. This will enable the SQL service endpoint for the selected subnet.

After enabling service endpoints, this will create a specific route in the Virtual network for Azure SQL PaaS. However still the destination service (SQL PaaS) has public IP address. The access restriction is enabled on SQL PaaS that only traffic originating from a specified Virtual network/subnet will be allowed.

Log into a VM with appropriate credentials and run below PowerShell command to verify SQL connection from VM:

Test-NetConnection -ComputerName az-sql-server01.database.windows.net -Port 1433

let’s check network routes, click on Network interface of Virtual machine and click effective routes:

Discussion point: SQL PaaS server is resolved to its public IP address and it shows connection happens via public IP address with Microsoft as the backbone. We can see a new route, which is for Azure SQL PaaS, where the next-hop type is VirtualNetworkServiceEndpoint. This confirms that Azure backbone will re-direct all Azure SQL traffic rather than going out via the internet, however, it has a public endpoint. This much more secure than earlier options.

For the Hybrid connectivity scenario model, where on-premise resources require connectivity to Azure SQL PaaS it requires Microsoft peering on express route for secure connection to happen with Microsoft backbone without reaching public internet. This requires a dedicated subnet.

Before we move to a private endpoint, let remove the service endpoint access.

1. Click on Firewall and virtual network in SQL Server and select earlier created rule and click delete.
2. Click on Virtual network and select VNET. Select service endpoints and click delete on SQL endpoints.

We can verify the network route for VM NIC, and the above-mentioned route will be deleted.

Method 3: Enable Private Endpoint:

Now on the same setup, let’s enable private endpoints for SQL PaaS service. Follow the below steps:

1. Click on SQL server and select Private Endpoint connections under security.
2. Click + private endpoint.
3. Provide below information for settings and click Ok.

• Name: SQL-prvservice
• Region: select your appropriate region.
• Click: Next

4. On the resource section, select below settings:

• Connection method: Connect to an Azure resource in my directory
• Subscription: Select your subscription
• Resource Type: Microsoft.sql/servers
• Resource: select your Azure SQL server
• Target sub-resource: select your database on Azure SQL server
• Click: Next

5. On the configuration section, select below settings:

• Virtual network: select the virtual network, where VM is running.
• Subnet: Select the subnet of VM is created and running.
• Integrate with Private DNS zone: Yes
• Leave default on the DNZ zone.

6. Click Review + create and once validation passed click create.

After enabling private endpoints, we can see private endpoints and network interface cards (NIC) in the resource group. The NIC will have a dynamic private IP from VNET.

By choosing to integrate with a Private DNS Zone, DNS records are is created with a CNAME record mapping the public DNS to the private DNS (“privatelink.database.windows.net”) and an A record mapping the private DNS to the private IP address.

Log into a VM with appropriate credentials and run below PowerShell command to verify SQL connection from VM:

Test-NetConnection -ComputerName az-sql-server01.database.windows.net -Port 1433

Results:

let’s check network routes, click on Network interface of Virtual machine and click effective routes:

Discussion point: SQL PaaS server is resolved to its private IP address and it shows connection happens via VNet and nothing outside of it (as long as the public access has been blocked). We would see private IP address name resolution for SQL PaaS service, which means the service is added to your VNET and no more public.

We can see a new route, which is for Private IP address added to Azure SQL PaaS service, and next-hop type is InterfaceEndpoint. This confirms that the Azure backbone will access all Azure SQL traffic over your virtual network rather than going out via the internet, and SQL PaaS has a private endpoint.

For Hybrid connectivity, this option does not require Microsoft peering and only private peering on express route for secure connection to happen within Azure VNet. This method provides a greater security options where we can now connect to Azure PaaS resources from the on-Premise network via Private Peering 

Key things:

• With enabling a Private endpoint, we can have Azure PaaS with a private IP address. This allows on-premise to connect Azure PaaS with Private peering on the Express route.
• With hybrid cloud deployment, a private endpoint is more secure.
• The azure monitor supports Azure Private Link as data processed by private endpoint.
• Private endpoints can connect to Azure PaaS across AD tenants and Azure regions.
• Private endpoints ignore NSG and UDR specified on the subnet
• Private endpoint is a way to secure traffic from on-premise to Azure when you only have private peering so the requirement for Microsoft peering becomes further diminished