Securing your Azure App Service with vNet’s and Service Endpoints

When I meet with a customer and we talk about migrating their apps into Azure there is always discussion around how to secure their applications in the cloud.  Your application can consist of a simple website with a database or even something that requires a multi-tiered architecture.  Most customers look to take advantage of PaaS (platform as a service) because of its many benefits: an abstraction of the operating system, highly available and focusing on code first.  It’s what all developers want to have but then the security and networking routing questions come into play.  When you build an Azure WebApp you are given an external routing configuration that allows that service to be access from public endpoints.  Up to now, you were only able to connect to these services via a public endpoint.

If a customer required access through an ‘internal’ IP address or lock down a back end service, this had to be achieved using traditional virtual machines, AKS (Azure Kubernetes Service), or App Service Environment (ASE).  ASE is a great option to provide the connectivity requirements that most people wanted; ASE allows for high scalability, isolated and secure network access but comes with a heavy investment in costs to run an application. For many users, making the decision to migrate to a purely PaaS environment quite difficult.  I have a mix of customers running their websites on virtual machines due to legacy issues, or ASE to take advantage of virtual network support.

Finally, we have an answer!   A newly released feature for Azure WebApps allows for virtual network integration. WINNER!  With the introduction of vNet integration, it means you can also enable service endpoints, allowing you to lock down incoming traffic from ‘internal’ IP addresses. When I refer to internal, I mean anything in your Azure virtual network and not coming from a public source.  Added features include adding Access Restrictions to our WebApps that allow for IP whitelisting for incoming requests.  This is immensely useful for customers that have strict access requirements to their websites.  An example, my customers in the health sector may require access to their website directly through HSCN connectivity.  With the addition of ExpressRoute and some routing protocols, we can enable internal access from a set of whitelisted IPs on the HSCN network.

There are quite a few Azure services that are generally available: Key Vault, Event Hubs, Azure SQL DB and Service Bus (just to name a few).  How exactly does this improve security for our resources? We are fully removing public internet access to our resources and configuring optimal routing for Azure traffic.  Using the Azure backbone network, you can audit and monitor outbound internet traffic on your resources and your virtual network, eliminating bottlenecks and performance issues from your applications. 

For multi-tiered applications, we can route back end APIs, websites, etc through the virtual network.  You will need to configure a Service Endpoint and create a custom route that all traffic for your designated Azure resource to follow.

To further lock down our virtual network, we can deploy an Application Gateway that would sit on the in front of our Azure WebApp(s). The diagram below is a very high level overview of how API management can be configured using service points, allowing for controlled access to an external API (used for access from 3^rd parties, etc) and an internal API that would be accessed from an internal user:

Deploying your WebApp is really easy.  I have an existing vNet in my Azure subscription and I would like to add it to my WebApp. Currently my WebApp is only available via a public IP address.  To start, I go into an existing virtual network and ensure that ‘service endpoints are enabled’:

I go into my existing Azure WebApp, select ‘networking’ and then select ‘vNet Integration’.  The vNet Integration page will come up and show that I don’t have any vNet’s configured.  I click on ‘Add vNet’ and select the virtual network and subnet that I’d like my WebApp to reside on, and voila!  I have a virtual network assigned to my Azure WebApp.

From the Networking page, I can then go onto to configure Access Restrictions, etc.  I can remove access from external IP addresses, or white-list internal IP addresses if required. 

This new feature has increased the security capability of several Azure services and still allows for you to deploy code first into various Azure PaaS services! For those consuming virtual machines or WebApps in ASE, now is a great time to migrate them into Azure WebApps using Service Endpoints.