Blog Post

Apps on Azure Blog
3 MIN READ

Secure storage account linked to Function App with private endpoint

Linru_Hui's avatar
Linru_Hui
Former Employee
Aug 16, 2021

Azure are offering to restrict the storage account to a virtual network. This feature currently works for all Windows virtual network-supported SKUs in the Dedicated (App Service) plan and for Windows Elastic Premium plans. It is also supported with private DNS for Linux virtual network-supported SKUs. Consumption and custom DNS for Linux plans aren't supported.

 

One can follow below steps to apply the configuration.

 

Prerequisite:

Function App:                   Need to be Elastic Premium plan to support Vnet integration

Storage Account:              Need to be StorageV2 (general purpose v2) or higher to support Private Endpoint

Vnet:                                 Needs to have two subnets, one is for function app, the other is for Private Endpoint for storage account

 

Detailed steps:

1. Create Function App on Elastic Premium plan, the binding storage account needs to be with pricing tier general purpose v2 or higher to support private endpoint. Both function app and storage account should be hosted in the same region for better performance.

If you created a lower pricing tier for storage account, you can go to portal through blade “Configuration” to change the pricing tier.

Function app:

 

Storage account:

 

2. Create Vnet and prepare two subnets. As mentioned previously, one is for function app, the other is used to enable Private Endpoint in storage account.

 

 

3. Integrate Vnet with your function app, select the subnet dedicated for your function.

 

 

 

 

 

4 Go to portal storage account, in blade Networking, select Tab “Private endpoints connections”.

4.1 Click on “+ Private endpoint”;

4.2 Input name for Private endpoint, then click Next: Resource

4.3 In the next page, choose storage account for “Resource type”, select the corresponding storage account, then select the target sub-source.  For function apps, you need to provide private endpoint for file and blob.  Click Next.

4.4 In configuration, select the vnet and subnet for private endpoints. Then review and create.

4.5 We need to create file and blob for function app, then go the whole scenario again to crate private endpoints for file. I myself created 4 private endpoints, blob, file, queue and table respectively.

 

 

 

 

 

 

 

5. Set up firewall in storage account, blade “Networking” , allow access from existing two subnets of Vnet.

 

6. Something need to be caution here, we need to add corresponding app settings WEBSITE_CONTENTOVERVNET, WEBSITE_DNS_SERVER, and WEBSITE_VNET_ROUTE_ALL  in order to make this feature work.

 

There is one thing you should be careful of when making these settings, as described in the feature documentation – the above settings should be set at the same time (in the same operation) as you set the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING setting. This prevents some “confusion” on the Windows OS end when accessing the network share. Ordinarily, this would be set in a single ARM template, so all of the settings would naturally be set at the same time, but when experimenting in Portal, it’s easy to get the order wrong. Therefore, when enabling the feature on this site, you should first remove the Azure Files connection string (or point it somewhere else), wait a few minutes, then set the connection string at the same time as the other settings mentioned above.

 

Once done, it should be like this:

 

 

7. About runtime error reported in function portal – wake up the function runtime by accessing kudu site.

There is also sometimes a slight irregularity in how the feature interacts with Portal. It may report the “function runtime unreachable” error even when the feature itself is working as intended. Therefore, to verify whether the site is active, go to the SCM site’s Debug Console and verify that the content browser loads as usual. This “wakes up” the functions runtime and restores its connection to Portal.

 

Test with different deployment methods:

Storage account is secured with firewall. Private Endpoints also grant smooth deployment experience from both VSTS and Web Deployment.

Try deploy with Azure DevOps, it ended with success.

 

 

Try deploy from local PC (it is not using the same code base as we used in Azure DevOps, after deployment it should have 3 functions)

 

 

 

 

 

 

Updated Aug 13, 2021
Version 1.0

4 Comments

  • Hi Linru_Hui ,

     

    Just to add after my question, I've solved the requirement of 5. Set up firewall in storage account, blade “Networking” , allow access from existing two subnets of Vnet by creating a new private endpoint for the fileshare of the storage and then disabling the 'public network access' completely. This will ensure that the function acecsses the storage only through private endpoints.

    Most important pieces of configuration for my Azure function hosted with private endpoint was the WEBSITE_DNS_SERVER entry, without which it was not able to find the storage.

     

    However, the slot swap is still now working from Azure DevOps using Microsoft hosted agents and I had to use Self hosted agents under my VNET.

     

  • kspoojary's avatar
    kspoojary
    Copper Contributor

    Hi Linru_Hui 
    If we restrict the storage account access then swap slot is not working.

    Please check my post 
    https://stackoverflow.com/questions/72025235/azure-functions-swap-functionality-is-not-working-after-enabling-private-endpoin

  • Hi Linru_Hui,

     

    Thanks for this excellent guide. I have the following confusion on step #5, "5. Set up firewall in storage account, blade “Networking” , allow access from existing two subnets of Vnet." - this will create two new service endpoints to this storage account, each associated with the subnets we are adding in the networking restrictions. i.e., we will have 2 service endpoints and n private endpoints (depending on the number of services used, table/ queue/ blob etc.). Is this the recommended way? I am wondering if there is a way to restrict the connectivity through private endpoints only.

     

    Thank you!!

     

  • Darrell's avatar
    Darrell
    Copper Contributor

    Hi Linru_Hui , thanks for the guide. I have a couple of questions after trying this with Linux based Function app P1v2 (which failed):

     

    Can you confirm that "custom DNS for Linux plans aren't supported" means that WEBSITE_DNS_SERVER must use 168.63.129.16?

    Is WEBSITE_VNET_ROUTE_ALL still required after the latest vnet integration updates?

    This process differs from the documented guide https://docs.microsoft.com/en-us/azure/azure-functions/configure-networking-how-to#restrict-your-storage-account-to-a-virtual-network, when I follow that guide it works but it is not something that will be easy to automate :unamused:.

     

    As I said my own portal deployment following these steps failed. Function runtime not accessible/service unavailable when trying to access the scm. Any possibility of providing an example ARM/Bicep/Terraform template?

     

    Thanks

    Darrell