Securing Back-end App Service Web Apps with VNets and Service Endpoints

Suppose you have an application that consists of a "front-end" website, and a back-end web API. You want the end users of your application to be able to access the front-end website, but you only want the front end to be accessible to your end users. The back-end should be locked down so it is only callable from the front-end.

This is a fairly standard architecture, and is quite easy to achieve in Azure with traditional VMs in a Virtual Network, or with AKS. You simply only expose public endpoints for the front-end services you want to make available.

Unfortunately, if you're using App Service, with your front-end and back-end services hosted as Web Apps, there hasn't been an easy way to do this until recently. That's because there is no way for a Web App hosted on App Service to join a Virtual Network, unless you choose the "ASE" (App Service Environment) pricing tier, which is prohibitively expensive for many scenarios.

Restricting access to Web Apps

Now of course, you can (and should) protect your back-end API by requiring all callers to provide credentials, and encrypt the traffic with TLS. But we'd like to go further than that. Ideally, even if credentials to call the back-end API were leaked, they still shouldn't be usable by any attacker on the internet - we'd like to accept only traffic originating from trusted locations.

App Service does help us out a bit here. As well as securing our endpoints in the usual way, we can add Access Restrictions to our Web Apps. This way we can whitelist the IP addresses that are allowed to make incoming requests.

This is great for your front-end web app if you happen to know the exact IP addresses that your customer will use. That way you can prevent all and sundry from visiting your site and trying to brute force the login screen.

But if the back-end API is intended to to be called only by the front-end web app, then we have to whitelist all possible outbound IP addresses for the App Service plan that the front-end web app is hosted on. And those IP addresses are not exclusive to our front-end web app. It would be possible for other apps running on App Service in the same data center to attempt to access our back-end API.

Service Endpoints and new VNet integration to the rescue!

The good news is that by using a mixture of "Service Endpoints" alongside the new Virtual Network integration feature for App Service, you can completely lock down access to your back-end APIs, and only allow incoming traffic from the web apps that should be calling them.

Essentially we can force all outbound requests to the back-end service from the front-end service to flow through a Virtual Network. And then we can configure the back-end service to only accept traffic from that Virtual Network.

And how do we make the outbound requests go through the Virtual Network, and not take some other route? That's what the "Service Endpoints" do. Essentially they set up a custom route that all traffic for a particular Azure service (in our case App Service), will follow.

Demo overview

In the rest of this post, I'll show the steps to set this all up. Here's a quick overview of the key steps:

1. Create a Virtual Network
2. Create a delegated subnet, and enable a service endpoint for App Service
3. Create an App Service Plan and front-end and back-end web apps
4. Add an access restriction for the back-end web app to only allow traffic from the subnet
5. Connect the front-end web app to the vnet
6. (optional) connect the back-end web app to the vnet

Step 1 - create the virtual network

First we need to create a Virtual Network. I'll create a resource group to put everything in:

$resourceGroup = "VNetTest"
$location = "westeurope"
az group create -n $resourceGroup -l $location

And create a new VNet:

$vnetName = "vnettest"
$vnetAddressPrefix = "10.2.0.0/16"
az network vnet create -n $vnetName `
    -g $resourceGroup `
    --address-prefix $vnetAddressPrefix

Step 2 - Create a delegated subnet

We need to create a delegated subnet in our VNet that all traffic from our front-end web app will travel through. The key things here are to add a delegation of Microsoft.Web/serverFarms and enable the service endpoint of Microsoft.Web. A prefix of /27 is allows sufficient addresses for this subnet.

$subnetName = "delegatingsubnet"
az network vnet subnet create `
    -g $resourceGroup `
    --vnet-name $vnetName `
    -n $subnetName `
    --delegations "Microsoft.Web/serverFarms" `
    --address-prefixes "10.2.1.0/27" `
    --service-endpoints "Microsoft.Web"

Step 3 - Create the app service plan and web-apps

Now we'll create an App Service plan (which needs to be a "standard" plan or above) and two web apps - one for the front-end and one for the back-end.

$appServicePlanName = "TestAppServicePlan"
az appservice plan create -n $appServicePlanName `
        -g $resourceGroup --sku S1 

$frontendAppName = "frontend-01a"
az webapp create -n $frontendAppName -g $resourceGroup -p $appServicePlanName
$backendAppName = "backend-01a"
az webapp create -n $backendAppName -g $resourceGroup -p $appServicePlanName

I also uploaded a couple of simple test apps to the web apps, so that I could test connectivity from the front-end to the back-end.

Step 4 - Lock down the back-end

Now, let's block any incoming traffic to the back-end web app that doesn't come from the VNet.

It's a little bit fiddly to automate with the Azure CLI from PowerShell as getting your JSON correctly escaped can be tricky, but essentially we're just adding a new "IP security restriction" that points at the resource ID of our delegated subnet.

$subscriptionId = az account show --query id -o tsv
$subnetId = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName"
$restrictions =  "{ \""ipSecurityRestrictions\"": [ { \""action\"": \""Allow\"", \""vnetSubnetResourceId\"": " +
                    "\""$subnetId\"", \""name\"": \""LockdownToVNet\"", \""priority\"": 100, \""tag\"": \""Default\"" } ] }"

az webapp config set -g $resourceGroup -n $backendAppName --generic-configurations $restrictions

If all works correctly, it will be impossible to make a call to the back-end web app from the public internet, and the front-end web app will also be denied access.

Step 6 - Connect front-end to the VNET

Now we need to connect the front-end web app to the VNet. This is so that any outgoing traffic from the front-end web app will get routed through the delegated subnet and therefore be allowed to access the back-end.

This is unfortunately not a feature that is supported by the Azure CLI, and I found the documentation on how to call the REST API directly very difficult to follow. In the end I used the F12 tools in my browser to see what the Azure Portal does when you join a web app to the VNet. This revealed the endpoint I needed to call (/config/virtualNetwork) and the format of the payload (including the swiftSupported flag).

I then created the following PowerShell function to connect a web app to a specific subnet in a VNet:

function Join-Vnet ($resourceGroup, $webAppName, $vnetName, $subnetName)
{
    $subscriptionId = az account show --query id -o tsv
    $location = az group show -n $resourceGroup --query location -o tsv
    $subnetId = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName"

    $resourceId = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Web/sites/$webAppName/config/virtualNetwork"
    $url = "https://management.azure.com$resourceId" + "?api-version=2018-02-01"

    $payload = @{ id=$resourceId; location=$location;  properties=@{subnetResourceId=$subnetId; swiftSupported="true"} } | ConvertTo-Json
    $accessToken = az account get-access-token --query accessToken -o tsv
    $response = Invoke-RestMethod -Method Put -Uri $url -Headers @{ Authorization="Bearer $accessToken"; "Content-Type"="application/json" } -Body $payload
}

And we can use it to join the front-end app to the VNet:

Join-Vnet $resourceGroup $frontendAppName $vnetName $subnetName

With that done, our front-end should be able to communicate again with the back-end. I've noticed that the change isn't always immediate - sometimes it can take a minute or two before you are able to access.

Step 7 - (Optional) Connect Back-end to VNet

If you have multiple back-end services, they also may need to communicate with each other. That can be achieved by connecting the back end web-app to the VNet as well. We can reuse the function we just created:

Join-Vnet $resourceGroup $backendAppName $vnetName $subnetName

Summary

In this post we saw how to secure the back-end tier of a multi-tier web app, by making use of some new App Service features, and without having to use the expensive App Service Environment features. In fact, the costs for setting this up are minimal, and represents true defence in-depth for your back-end services.

Obviously, we've not talked about restricting access to the front-end. You might also want to lock that down to a VNet as well depending on your use case. That can be achieved by creating an Application Gateway and only allow incoming traffic to the front-end to come from that. I've also managed to set that up for an App Service, but I'll save that for another post, because it was quite a complex process.