Application Gateway and app services:

Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications. When compared to Azure Front Door that offers global load balancing across regions and is preferred for direct connectivity to the internet, App Gateway is suitable for backends contained within a region or is not open to the public internet. Both provide web application firewall and App Gateway provides features such as SSL/TLS termination, autoscaling, zone-redundancy, static VIP, Ingress controller for Azure Kubernetes Service resources, URL based routing, multiple site hosting, redirection, session affinity, websocket and http/2 traffic, connection draining, custom error pages, rewrite of http headers and URL, and sizing. It is preferable to choose the v2 sku that includes the WAF.

The declaration for this resource takes parameters to describe the backend and its https settings and together the gateway and its backend can fulfill all expectations for load balancing and routing including restricting access to the backend from the internet and making them available to the application gateway. It requires some configuration on both the backend as well as the application gateway and this article calls them out.

First, the application gateway can have a wide variety of backend from sites hosted on Virtual machine scale sets to function applications even though it is primary for application layer load balancing with traffic over http/s. In this case, we take a simple case of an application gateway load balancing between a web application and a function application. The backend can be described by ip addresses as well as fully qualified domain names. The latter is preferable because we do not need to set vnet integration and call out the private link. It will resolve the private link when available and throw an error when accessed via the public when the private link is set up. A private link avoids sending the traffic over the internet and keeps it within the region. The backend should include the full name for the web app and function app for our example.

The backend http settings are described with the port, protocol, path, timeout, and other parameters. It must have cookie-based affinity enabled or disabled and it is preferable to keep it disabled. The http settings also include a reference to a probe which allows us to diagnose the health of the backend services.  The probe takes similar parameters as the http settings to make an http request to a specified path and can even pick the host name from the backend settings. Writing custom probes is preferable when the path is custom, or the responses are also meaningful to the health check in addition to the status codes.

As with any firewall, the application gateway must declare the routing rules and the http listener that should be used with the matches. The redirects and rewrite rule sets can also be specified here along with a priority for the ordering of rules. The gateway must have a private address as well as a public address when it is to be reached from both networks.

The applications must specify addresses to accept traffic from as the private address of the application gateway. They must also specify CORS by setting the Access-Control-Allow-Origin response header.  This completes the restriction of traffic to the backend from public internet and permitted only via the application gateway.

Some practice applies as with many Azure resources. For example, the portal advisor might suggest that some of the features are unnecessarily turned on. It is possible to avoid custom probes altogether but the reason the documentation recommends it is that those probes help you articulate what must be monitored.

Similarly, there are features on the application gateway that can provide “insights” into the working of the application gateway. These are displayed from the metrics that the resource collects. There are resources external to the gateway such as Network watcher that can help with troubleshooting network connectivity issues.

SSL profiles help to configure client authentication as well as listener specific SSL policy. A certificate is added to the profile, but this can be skipped when all the app services in the backend pool are internal.

The same applies to rewrites and redirections that can be avoided if the application gateway can pass through. The rewrite sets and the routing rules must be associated.

Some examples of setting up the application gateway will show url path maps to include wild card characters. If the paths are different between the rules so that the request matches one of them correctly, this is fine. Some usages write the rules such that they match more than one with the final match as the most qualified path. This could be avoided because discrete enumerations of the rules are much easier to test, diagnose and maintain.

Sample URL maps could be as follows:

  url_path_maps = [

    {

      name                               = "gw-url-path"

      default_backend_address_pool_name  = "app-gw-centralus-bapool01"

      default_backend_http_settings_name = "app-gw-centralus-be-http-set1"

      path_rules = [

        {

          name                       = "api"

          paths                      = ["/api/*"]

          backend_address_pool_name  = "app-gw-centralus-bapool01"

          backend_http_settings_name = "app-gw-centralus-be-http-set1"

        },

        {

          name                       = "videos"

          paths                      = ["/videos/*"]

          backend_address_pool_name  = "app-gw-centralus-bapool02"

          backend_http_settings_name = "app-gw-centralus-be-http-set2"

        }

      ]

    }

  ]

 

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)