Azure: Deploy a WebApp with a Network Security Group

calendar Jan 12, 2022 · 3 min read · microsoft azure powershell app-service  ·
Share on: linkedin copy

Overview

A preview Azure feature allows a WebApp to be hosted behind a Network Security Group. This post explains the architecture involved and how to deploy it.

An Azure Private Endpoint enables connection of a Application Service (Web App) to a Virtual Network (VNET), giving it a private IP rather than the public address usually associated with the .azurewebsites.net name. However prior to this preview it was not possible to use a Network Security Group (NSG) to restrict access to the website. When setting up an Private Endpoint a warning is issued to confirm this.

If you have a network security group (NSG) enabled for the subnet above, it will be disabled for private endpoints on this subnet only. Other resources on the subnet will still have NSG enforcement.

Once an account has been registered for the preview, NSG support for Private Endpoints can be configured on a per-subnet basis. This means it’s possible to be granular in deployment, and not run the risk of upsetting existing services in a tenancy or subscription.

Example Architecture

A prime example of how this feature can be used is to host a WebApp on a VNET behind an Application Gateway. The NSG can be used to lock down the WebApp subnet so only HTTPS (443) traffic is allowed in, and only from the Application Gateway. This ensures that users within the network cannot bypass the Web Application Firewall in the App Gateway by going directly to the .azurewebsites.net address.

Configuration

Firstly a Web App is required. This must be (at time of writing, January 2022) on the Elastic Premium, Premium V2, or Premium V3 SKU- this functionality is not available on the Free, Basic, or Shared tiers.

Configure Private Endpoint

To configure the private endpoint in the Portal, go to the WebApp (1) open the Networking blade (2) and click on Private endpoints (3).

On the Private Endpoint connections blade, click on Add (4).

Enter a name for the new Endpoint (5), and the VNET (6) and Subnet (7) it’s going to reside in.

Save that, and once deployed the Networking blade on the WebApp should now show that Private endpoints are On and the Inbound address is now in the private range from your subnet.

Configure DNS

Setting up the Private Endpoint creates a DNS alias on the azurewebsites.net, for example myexampleapp.azurewebsites.net would be given the DNS alias myexampleapp.privatelink.azurewebsites.net.

An authoritative zone privatelink.azurewebsites.net is required in your internal DNS (as used by the VNET), and then an A record for each WebApp with a Private Endpoint. For example,

1A   myexampleapp.privatelink.azurewebsites.net  10.0.1.20

Enable Preview

The preview can be enabled with PowerShell.

1Register-AzProviderFeature -FeatureName AllowPrivateEndpointNSG -ProviderNamespace Microsoft.Network

This takes a few minutes to register, you can check progress using the following cmdlet- wait for it to return Registered.

1Get-AzProviderFeature -FeatureName AllowPrivateEndpointNSG -ProviderNamespace Microsoft.Network

1$vnet = Get-AzVirtualNetwork -Name 'MyVNETName' -ResourceGroupName 'MyVNETResourceGroupName' 
2($vnet | `
3    Select -ExpandProperty subnets | `
4    Where-Object {$_.Name -eq 'MySubnetName'}).PrivateEndpointNetworkPolicies = "Enabled"
5$vnet | Set-AzVirtualNetwork

Configure NSG

The rules in the NSG will depend on the surrounding architecture. In the diagram above, a rule should be in place to allow HTTPS traffic (TCP:443) from the Application Gateway subnet, and another to deny other traffic.

Resources