Securing Inbound Access to Azure App services using Azure Private Link

Microsoft has recently released a Public Preview of Private Link for Azure App Service.  This preview is available in limited regions for all PremiumV2 Windows and Linux web apps. Until this point securing App Services through Virtual Network Isolation was only possible through App Service Environments(ASE). ASE’s are generally expensive and have long initial deployment cycles as a drawback.

Private Link exposes your app on an address in your VNet and removes it from public access. This not only secures the app but can also be combined with Network Security Groups to secure your network.

The scenario we are trying to address here is blocking the public endpoint access for the webapp and see a use-case for Point-To-Site connection from your laptop to the webapp through the private endpoint. For Production scenarios my suggestion would be to setup either use a Site-Site VPN or Expressroute connection for a more secure approach.

Private Link use-case scenarios

[update] As of Aug 20′ This feature is currently available in preview in all public regions. For the scope of this blog post i will be creating the azure resources in SouthEastAsia region.

//create azure resource group
az group create --name psea-test-plink-rg --location southeastasia

//create azure app service plan
az appservice plan create --name psea-test-webapp-plan --resource-group psea-test-plink-rg --location southeastasia --sku P1V2 --number-of-workers 1

//create a web app under the app service plan
az webapp create --name psea-test-webapp --resource-group psea-test-plink-rg --plan psea-test-webapp-plan

//create a virtual network for private link integration
az network vnet create --name psea-test-plink-vnet --resource-group psea-test-plink-rg --location southeastasia --address-prefixes 10.8.0.0/16 --subnet-name plink-subnet --subnet-prefixes 10.8.100.0/24

//create a new subnet under the virtual network for private link integration
az network vnet subnet update --name plink-subnet --resource-group psea-test-plink-rg --vnet-name psea-test-plink-vnet --disable-private-endpoint-network-policies true

//create a private endpoint for webapp
az network private-endpoint create --name psea-test-plink-ep --resource-group psea-test-plink-rg --vnet-name psea-test-plink-vnet --subnet plink-subnet --connection-name webapp-conn --private-connection-resource-id /subscriptions/xxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx/resourceGroups/psea-test-plink-rg/providers/Microsoft.Web/sites/psea-test-webapp --group-id sites

//create a private DNS zone 
az network private-dns zone create --name 
privatelink.azurewebsites.net --resource-group psea-test-plink-rg

//link private DNS with virtual network
az network private-dns link vnet create --name private-dns-link --resource-group psea-test-plink-rg --registration-enabled false --virtual-network psea-test-plink-vnet --zone-name privatelink.azurewebsites.net

//link private endpoint to the private DNS
az network private-endpoint dns-zone-group create --name private-dns-zone --resource-group psea-test-plink-rg --endpoint-name psea-test-plink-ep --private-dns-zone privatelink.azurewebsites.net --zone-name privatelink.azurewebsites.net

Once the Private Link Endpoint is created, you would see a Network Interface created with a Virtual Network mapped to a subnet. For our scenario trying to establish inbound connection to the webapp through Point2Site Connection, we can have to create a VPN Gateway

az network vnet-gateway create -n psea-test-vnet-gway -l southeastasia --public-ip-address psea-test-vnetgway-pip -g psea-test-plink-rg --vnet psea-test-plink-vnet --gateway-type Vpn --sku VpnGw1 --vpn-type RouteBased --no-wait

For establishing a P2S VPN connection using a VPN gateway, we either follow Microsoft documentation here or more accurately as per the steps mentioned here. Once the P2S connection on your personal laptop is established you would see a 403 error when you try to navigate to https://psea-test-webapp.azurewebsites.net/

Try setting the etc/hosts file with the private IP and the webapp name and you should be able to navigate to web app with out any issues.

2 comments

  1. I am confused as to how this is useful. What does moving the public access to an App Gateway matter if the requests still get passed through to the App Service anyway? How is a public IP on an App Service inherently insecure when compared to a public IP on an App Gateway that just funnels to an App Service?

    Like

    1. Hi Dave,
      Thanks for your feedback. Agree with you on the point about using Public End point on App Gateway. I just though that the use case scenario i picked for the post may not be right so I have made some changes to the post w.r.t the scenario and the approach to validate Private endpoints with webapp. Please have a look.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s