Securing backend AppServices with VNET integration: Part 2
Pascal van der Horst
Pascal van der Horst
 4 Minutes

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


Creating backend appservice - 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


Creating backend appservice - 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>, an HTTP status code 200 is returned to the data output browser.

Creating backend appservice - testing

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. 

Isolating backend appservice - VNET

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>, a HTTP status code 403 is now returned to the browser.

Isolating backend appservice - 403

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

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

  • azure
  • cloud
  • security
  • backend
Pascal van der Horst
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.