Restricting access to Azure app services to come via the application gateway:

When an app service or a multi-tenant service is added as a backend pool member, it will retain its individual IP address that can be reached from the public internet. This is great for development purposes and troubleshooting when the application’s features are being developed but when it is deployed to production its access is protected with some restriction rules. This article explains how to do that.

The options to add more restrictions include 1. Configuring access restriction rules based on service endpoints and 2. using Azure App Service static IP restrictions. The first option allows us to lock down the inbound access to the app making sure the source address is from application gateway. The second restricts the web application so that it only receives traffic from the application gateway. The app service IP restriction feature lists the application gateway VIP as the only address with access.

The option to add access restriction rules based on service endpoints is not supported on applications that have private endpoint configured or on apps that use IP-based SSL.  The service endpoints allow us to lock down inbound access to the application so that the source address must come from a set of subnets that we select. This feature works together with IP access restrictions. The process for setting service endpoints is like the process of setting IP access restrictions. An allow/deny list of access rules is authored that includes the public addresses and subnets in the virtual network. The VNet service endpoint provides secure and direct connectivity to Azure services over an optimized route over the Azure backbone network. Service endpoints enable private IP addresses in the VNet to reach the endpoint without going over the internet. The VNet Service endpoint provides the identity of the virtual network to the Azure service. When a service endpoint is enabled, we can add a virtual network rule to secure the Azure service resource to the virtual network.

The second option, similarly, requires us to define an allow/deny list that controls network access to the app not the VNet and these rules are priority ordered. This list can include IP addresses or Azure Virtual Network subnets. Even if one entry is specified to allow or deny, an implicit deny all is added to the end of the list. This capability works will all web apps, API apps, Linux apps, custom containers, and functions. When a request is made to your app, the FROM address is evaluated against the rules in the access restriction list. If the FROM address is in a subnet that’s configured with service endpoints to Microsoft.Web, the source subnet is compared against the virtual network rules in the specified access restriction list. If the access is denied, a 403 error is returned. This capability is implemented in the app service front-end roles which are upstream of the worker hosts where the code runs. These restrictions therefore are effectively network Access Control Lists (ACLs)