Securing backend AppServices with VNET integration: Part 2

In the second part of the "Securing backend AppServices with VNET integration" tutorial, a backend/API AppService will be created and configured to use the Azure Virtual Network. The goal is to isolate the backend service.

Creating the backend AppService

To create an Azure AppService, only the following tabs are discussed and explained:

Basics
Monitoring

Basics

When creating an Azure AppService, a number of properties must be configured.

Subscription
Select the subscription to recover the costs incurred.
Resource group
Select the resource group that the Azure AppService should enter.
Name
Name the Azure AppService. Keep a naming convention in mind..
Publish
Select here whether the code should be executed or whether a docker container should be deployed.
Runtime stack
Select the right technology stack. This example uses .Net core 3.1 framework.
Region
Select the right region. The region must be the same as what the Azure Virtual Network is. If the regions differ, there will also be costs mapped for inbound (Ingress) and outbound (Egress) bandwidth
AppService plan
Select the right service plan with VNET support. VNET support is available in Standard and Premium.

Then press Next: Monitoring

Monitoring

For completeness, we also configure Application Insights for the backend. Then press Review + create to create the Azure AppService. Resource creation takes up to 5 minutes.

Testing the backend AppService

After the Azure AppService is created, the weatherforcast(code) example is deployed to the backend AppService. When running the url: https://<backing app service name>.azurewebsites.net/weatherforecast, an HTTP status code 200 is returned to the data output browser.

The backend service is available from all browsers over the internet. A malicious user could theoretically execute requests on the backend service causing the service to:

no longer perform. This also causes a delay to the frontend service and a timeout may occur.
allowing the service to other services , hosted on the same hosting plan, are allocating fewer CPU and memory resources.
increase page requests, dependencies, traces and exceptions, to Application Insights. The first 5GB of logging may be free, but every GB that is exceeded, must be paid for.

Restrict access to the backend AppService

To secure the backend AppService, we can apply IP restrictions. Requests from the set IP address are then allowed and anything that is not configured is blocked.

In this case, requests from the frontend AppService will also be blocked!!!

That's not the point. By adding the subnet of the virtual network to the list of IP restrictions, this can be prevented.

Press Configure Access Restrictions under the heading Access Restrictions.

Isolating backend appservice - networking

In this screen, an Access Restriction rule can be configured that allows traffic only from the virtual network. This requires several properties:

Name
A name for the Access Restriction.
Action
Allow. In this case, traffic should be allowed from an Azure resource.
Priority
The lower the number, the more priority the Access Restriction rule has.
Description
A description of the Access Restriction.
Type
Virtual Network. The other options are IPv4 and IPv6 for IP restriction.
Virtual Network
Select the virtual network created in part 1.
Subnet
Select here the delegating subnet which was also created in part 1.

Press Add rule to add the restriction.

Isolating backend appservice - Access Restrictions

After the Azure AppService is paired with the virtual network, another test can be performed. When running the url: https://<backing app service name>.azurewebsites.net/weatherforecast, a HTTP status code 403 is now returned to the browser.

As a result, it is no longer possible to access the backend AppService. Only AppServices that have access to the virtual network can access the backend AppService.

Note: For development and diagnostic purposes, an IP restriction can be added to the backend AppService.

Creating and isolating of the AppService can also be automated with PowerShell or Azure CLI. An example of an Azure CLI creation script.

# variables
$resourceGroup = "rg-secure-connect"
$appServicePlanName = "hp-secure-connected"
$vnetName = "vnet-secure-connect"
$subnetName = "delegatingsubnet"

# creating hosting plan
az appservice plan create -n $appServicePlanName `
        -g $resourceGroup --sku S1 

# creating backend appservice
$backendAppName = "as-secure-backend"
az webapp create -n $backendAppName -g $resourceGroup -p $appServicePlanName

# backend appservice vnet restriction
$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\"": \""deligatingsubnet\"", \""priority\"": 6500, \""tag\"": \""Default\"" } ] }"

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

Handy resources

Do you have questions about securing backend AppServices? Get in touch, we'll be happy to help.

Pascal van der Horst

Pascal is specialized in designing and developing Microsoft .NET applications both on-premise and in the cloud (Azure) based on SCRUM methodology. He values qualitative and maintainable code, using design patterns and (cloud) principles as much as possible.