I am often asked how to secure access to and from Azure Functions that are not running in an App Service Environment (ASE). An App Service Environment allows you to safeguard your apps in a subnet of your Azure Virtual Network. In a sense, it gives you a private deployment of Azure App Service that you can secure with Azure Firewall, Network Security Groups (NSGs) or Network Virtual Appliances (NVAs).
When you use Azure Functions in a regular App Service Plan or Premium plan, you will need to rely on Virtual Network Service Endpoints and App Service network integration to achieve similar results.
In this post, we will look at an example of an Azure Function, running in a Premium plan, that queries CosmosDB. We will restrict incoming traffic to the Azure Function from a subnet and only allow CosmosDB to be queried by the same Azure Function. Here’s a diagram:
Incoming Traffic
To restrict incoming traffic to the Azure Function, navigate to the Function App in the portal and select Networking in Platform Features. You will see the following screen:
We will configure the inbound restrictions via Configure Access Restrictions. You can configure restrictions for both the Function App itself and the scm site:
From the moment you add rules, a Deny All rule will appear. In the above rules, I allowed my private IP and the default subnet in the virtual network. The second rule configures the service endpoints. When you open the properties of the subnet, you will see:
Great! When you try to access the function from any other location, you will get a 403 error from the Azure Functions front-end. So don’t expect a connection timeout like with regular network security rules.
Outgoing traffic
The example Azure Function uses an HTTP trigger and a Cosmos DB input (cosmos). Documents contain a name property. The query outputs the name found on the first document:
module.exports = async function (context, req, cosmos) {
context.log(cosmos);
context.res = {
body: "hello " + cosmos[0].name
}};
In order to secure access to Cosmos DB, two features were used:
- Azure Functions VNet Integration (VNet integration is currently in preview)
- Cosmos DB network service endpoints to restrict access to the subnet that provides the Azure Function hosts with an IP address
Configuring the VNet integration is straightforward, especially when compared to the old style of integration which required a VPN tunnel:
As you can see in the above screenshot, you delegate a subnet to the App Service hosts. In my case, that is subnet func-sec:
The bottom of the screenshot shows the subnet is delegated to the Microsoft.Web/serverFarms service. That is the result of the VNet integration.
You can also see the subnet has service endpoints configured for Cosmos DB. That is the result of the Cosmos DB configuration below:
In Cosmos DB, an existing virtual network was added. I did not enable the Accept connections from within public Azure datacenters option.
When you remove the service endpoint and you run the Azure Function, the following error is thrown:
Unable to proceed with the request. Please check the authorization claims to ensure the required permissions to process the request. ActivityId: 03b2c11f-2b21-44c9-ab44-61b4864539fe, Microsoft.Azure.Documents.Common/2.2.0.0, Windows/10.0.14393 documentdb-netcore-sdk/2.2.0
Does it work from a VM in the default subnet?
If all went well, I should be able to call the Azure Function from the virtual machine in the default subnet. Let’s try with curl:
The name field in the first document is set to itsme so it worked! Great, the function can be called from the default subnet. In case you are wondering about the use of -p in the ssh command: this virtual machine sat behind an Azure Firewall and the VM ssh port was exposed via a DNAT rule over a random port.
From another location, the following error is shown (wrapped around some HTML but this is the main error):
Error 403 - This web app is stopped
Conclusion
With virtual network service endpoints now available for most Azure PaaS (platform as a service) components, you can ensure those services are only accessed from intended locations. In this example, you saw how to secure access to Azure Functions and Cosmos DB. Service endpoints combined with the App Service VNet integration make it straightforward to secure a Function App end-to-end.
baeke.info 