Are you trying to determine the best way to secure your website hosted on Azure App Service? Do you want to leverage Azure App Service, but still restrict your site to internal users or your Network?
Background Information :
I think it’s safe to say, we all know that in Networking we have two key directions of traffic inbound and outbound. This is no different for an App Service, the reason I bring up this simple concept is because there are different architectural options to handle inbound/ingress and outbound/egress traffic to your app service. Today we will be talking about inbound traffic for your app service. If your looking for how to connect to resources in your VNET from your App Service, check out VNET Integration.
What do Service Endpoint and Private Link Solve :
In the past if you wanted to leverage PaaS services and you wanted to limit inbound traffic without a public IP, you would have to go with our higher tier plan called App Service Environment, which would deploy an App Service Environment into a VNET which would give you complete control of both inbound and outbound traffic. Another option would’ve been to still leverage App Service and use access restrictions to limit the IP addresses that would be able to access your App Service, however, this would still expose a public IP and your internal user traffic would be directed to your App Service over the public internet instead of using your Express Route or VPN Gateway.
Below is an example of what an App Service Environment Deployment would look like, you can see the users traveling over the internet, cannot reach your VNET (NSG configuration). However, most customers leverage a Hub and Spoke model, where they set up their Express Routes/Gateway, they then use VNET peering to their other VNETs that they’ve created in azure to this Hub VNET to extend their on premises data center to the cloud. (Firewalls, and all that good stuff still come into play)
The downside to App Service Environments, is really cost related. However, they really give you total control and depending on your company’s security requirements they may not want you running on shared infrastructure on the cloud. So their still a great option.
Service Endpoints allow you to restrict inbound/ingress traffic to your PaaS resources. With Service Endpoints, the PaaS service still exposes a public IP, and your traffic is leaving your virtual network to access the PaaS service. However, the PaaS service is configured to be able to identify traffic coming from your virtual network and allow that traffic to hit your PaaS service, without having to configure public IP’s on your VNET to allow filtering. With Service Endpoints we can limit and prevent traffic on our App Service to only resources within our VNET or any networks peered to our VNET, so no external traffic.
In the example below, I have configured an application gateway in my subnet, that leverages a service endpoint to communicate with my App Service. There are two parts to this configuration besides creating the App Service and the Application Gateway. The first part is enabling service endpoints in the subnet of the Virtual Network where the Application Gateway is deployed. Service endpoints will ensure all network traffic leaving the subnet towards the App Service will be tagged with the specific subnet ID. The second part is to set an access restriction of the specific web app to ensure that only traffic tagged with this specific subnet ID is allowed. You can configure it using different tools depending on preference.
Private Link for Azure App Service provides a way to inject the inbound/ingress of your web application into your virtual network. The benefits of Private Link is you no longer need to configure access restrictions, as your App Service, no longer exposes a Public IP Address. It is almost like your App Service resides in your VNET and your App Service is given a Private IP to communicate with resources in your VNET. It is like mimicking App Service Environment, but without the costs, and because it is a true PaaS service, it’s much quicker to create during a DR scenario.
In the example below, we combine both Private Link and VNET integration, to handle our inbound and outbound traffic to our App Service. Private Link handles traffic trying to hit our App Service any Traffic from our VNET our VNETS peered. While VNET integration allows our App Service to communicate with resources in our VNET and any resources that are peered to our VNET. In the example below our on-Premises users will go over Express Route to our Hub VNET and reach our App Service via VNET peering and Private Link. We no longer need an application gateway like we did with Service Endpoint, which also reduces cost. Our app service uses VNET Integration to connect to our PaaS SQL database, where we also used Private Link to handle the ingress/inbound traffic to our PaaS SQL database.
- Key Benefits of Private Link over Service Endpoint
- App Service Assigned a Private IP and Public IP isn’t exposed
- Application Gateway is not needed
- No longer required to set up access restrictions