Access restriction ServiceTag

Overview

Access restrictions for App Service have existed for a while and supports scenarios where you want to limit traffic to a web app or scm instance to a specific IP range or subnet using service endpoints. An upcoming changes, currently in preview, is the ability to specify Azure managed IP ranges defined as Service Tags. Service Tags will allow you to allow only traffic from specific Azure services such as EventGrid, Traffic Manager, Front Door or even App Service itself. In many cases you can also narrow it down to a specific region.

This feature is currently in preview. You are welcome to use the feature and provide feedback to madsd<at>microsoft<dot>com.

Behavior

When added, the normal IP CIDR is replaced with a Service Tag, and the CIDR(s) for this Service Tag is used instead. Azure takes care of keeping the IP ranges updated in case of any changes. To let the platform know you are specifying a Service Tag, you set the "tag" property of an access restriction to ServiceTag.

Use cases

A valid use case for this would be isolation of traffic between Azure Front Door and an App Service instance. In that case, you would use the "AzureFrontDoor.backend" Service Tag. To isolate it to your specific instance, you would need to add X-Forwarded-Host validation, which is another new feature of access restriction - described here. For creators of Azure Resource Manager Resource Providers, this can also be used to lock down traffic originating from ARM.

Usage

Test setup

Setup an Azure App Service web app [webapp-name]. Verify you can access the site using either a browser or curl

curl https://[webapp-name].azurewebsites.net

Adding access restrictions, as they are today, can be done using REST, ARM, portal, CLI and PowerShell. In the portal, you can find the access restriction settings under Networking:

In access restrictions you can add and remove individual restrictions as well as manage scm site restrictions and inheritance to scm site.

Debugging

It can be useful to see what values are actually sent to the web app. Using Kudo, you can add a .cshtml files, that can output relevant info. Create a file called default.cshtml and add the following content:

@using System.Web.Configuration

<h3>Debug information</h3>
<ul>
    <li><strong>Request Url</strong><span>: @Request.Url</span></li>
    <li><strong>X-Forwarded-For</strong><span>: @Request.Headers["X-Forwarded-For"]</span></li>
    <li><strong>X-Forwarded-Host</strong><span>: @Request.Headers["X-Forwarded-Host"]</span></li>
    <li><strong>Remote IP</strong><span>: @Request.ServerVariables["REMOTE_ADDR"]</span></li>
</ul>

• Open the Kudu console at https://[webapp-name].scm.azurewebsites.net and go to Debug console > CMD
• Browse to site > wwwroot and drag the default.cshtml to the folder.

You should now see an output like this:

Simple test with REST

Portal support for the new functionality is still pending, so you will need to use the REST apis to continue. To call REST you need to have ARMClient.exe installed. Follow this guide, if you do not have it installed already.

Test ARMClient.exe by getting the config section of the web site. If you are calling ARMClient.exe for the first time, you need to authenticate using ARMClient.exe login or ARMClient.exe azlogin. You can find Subscription ID and Resource group name in Azure portal in the Overview section of the web app. Site is your webapp-name (without .azurewebsites.net).

ARMClient.exe GET "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Web/sites/{site}/config/web?api-version=2020-06-01

Adding access restrictions uses the PATCH verb and need a payload in the form of a .json file. Create an clear.json file with an empty ipSecurityRestriction property:

{
  "properties": {
    "ipSecurityRestrictions": [
    ]
  }
}

Call ARMClient.exe with the payload (if you are calling from PowerShell, remember to back tick the @ sign).

ARMClient.exe PATCH "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Web/sites/{site}/config/web?api-version=2020-06-01 @empty.json

You should still be able to access the site.

Random Service Tag test

Add a random Service Tag restriction to verify you can block traffic - e.g. EventGrid in a file called random-tag.json and apply it using another call with ARMClient.exe

{
  "properties": {
    "ipSecurityRestrictions": [
      {
        "action": "Allow",
        "ipAddress": "EventGrid",
        "priority": 200,
        "tag": "ServiceTag"
      }
    ]
  }
}

ARMClient.exe PATCH "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Web/sites/{site}/config/web?api-version=2020-06-01 @random-tag.json

You should now receive a 403 error.

Azure Front Door test

Now lets setup the access restriction for traffic coming from AFD. First setup an AFD instance called [afd-name] and configure the traffic to point to your web app. Here is a guide to setup Azure Front Door with App Service. Clear the previous access restrictions by applying the empty json payload. Test that you can access the site from the Front Door address.

Create a payload file named afd.json with this content, and apply it using ARMClient.exe

{
  "properties": {
    "ipSecurityRestrictions": [
      {
        "action": "Allow",
        "ipAddress": "AzureFrontDoor.backend",
        "priority": 200,
        "tag": "ServiceTag"
      }
    ]
  }
}

You should now still be able to access the site through Azure Front Door, but you cannot access the site directly on the [webapp-name].azurewebsites.net address.

Azure Front Door extended tests

Currently it only locks down the site to the Front Door service and not your particular instance. To lock down the site to the particular AFD instance, you can apply the template below, and to verify that it works, you can create another AFD instance and verify, that you cannot access the web app from this instance. Azure Front Door will also send the client IP as XFF. You can further test the capabilities by adding the XFF in addition to XFH. You can now only access the site through Azure Front Door from your machine.

Note: Your XFF client IP may be an IPv6 address depending on the network your client is connected to.

{
  "properties": {
    "ipSecurityRestrictions": [
      {
        "action": "Allow",
        "ipAddress": "AzureFrontDoor.backend",
        "priority": 200,
        "tag": "ServiceTag",
        "xForwardedHosts": [
          "[afd-name].azurefd.net"
        ],
        "xForwardedFors": [
          "[your current IP]"
        ]
      }
    ]
  }
}

That's it. Happy acl'ing.