Logic Apps Preview enables hosting Logic apps runtime on top of App Service infrastructure and as a result inherits many platform capabilities that App Service offers. In this blog we are going to explore some of the network capabilities that you can leverage to secure your workflows running in Logic Apps preview.
Networking overview of Logic Apps preview
The azure storage that is configured in the default create experience will have a public endpoint that the Logic Apps runtime will use for storing state of your workflows.
The managed API service (azure connectors) is a separate service hosted in azure and is shared by multiple customers. The Logic Apps runtime uses a public endpoint for accessing the API connector service.
Securing Inbound Traffic Using Private Endpoints
See here for instructions for adding a private endpoint to your Logic App preview. When you add a private endpoint:
- The data-plane endpoint will resolve to the private IP of the private link and all public inbound traffic to your Logic Apps data plane endpoint will be disabled.
- Request triggers and webhook triggers will only be accessible from within your vNET.
- Azure managed API webhook triggers and actions will not work since they need a public endpoint for invocations.
- The monitoring view will not have to access to inputs and outputs from actions and triggers if accessed from outside of your vNET.
- Deployment from VSCode or CLI will only work from within the vNET. You can leverage deployment center to link your app to a GitHub repo and have the azure infrastructure build and deploy your code. In order for GitHub integration to work the setting WEBSITE_RUN_FROM_PACKAGE should be removed or set to 0.
- Enabling private link will not affect the outbound traffic and they will still flow through app service infrastructure.
An alternative configuration
- You can setup an application gateway to route all inbound traffic to your app by enabling service endpoint and adding a custom domain name for your app to point to the application gateway.
Securing Outbound Traffic Using vNET integration
To secure your outbound traffic from your web app, enable VNet Integration. By default, your app outbound traffic will only be affected by NSGs and UDRs if you are going to a private address (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
- To ensure that all your outbound traffic is affected by the NSGs and UDRs on your integration subnet, set the application setting WEBSITE_VNET_ROUTE_ALL to 1.
- Set WEBSITE_DNS_SERVER to 168.63.129.16 to ensure your app uses private DNS zones in your vNET
- Routing all outbound traffic through your own vNET allows you to subject all outbound traffic to NSGs, routes and firewalls. Note that an uninterrupted connection to storage is required for Logic Apps runtime to work and an uninterrupted connection to managed API service is needed for azure connectors to work.
- Enabling vNET integration does not impact inbound traffic which will continue to use App Service shared endpoint. Securing inbound traffic can be done separately using private endpoints as we discussed above.
Securing Storage Account by using storage private endpoints.
Azure storage allows you to enable private endpoints on storage account and lock it down to be accessed only within your own vNET. We can leverage this capability by enabling private endpoint on the storage account used by your Logic Apps.
- The setting AzureWebJobsStorage should point to the connection string of the storage account with private endpoints.
- Different private endpoints should be created for each of table, queue and blob storage services
- All outbound traffic should be routed through your vNET by setting the configuration WEBSITE_VNET_ROUTE_ALL to 1.
- Set WEBSITE_DNS_SERVER to 168.63.129.16 to ensure your app uses private DNS zones in your vNET.
- The workflow app should be deployed from Visual Studio Code and WEBSITE_RUN_FROM_PACKAGE config setting should be set to 1. Note that this will not work if you are also using private endpoint feature in which case you would want to leverage GitHub integration for deployment.
- A separate storage account with public access is needed for deployment and setting WEBSITE_CONTENTAZUREFILECONNECTIONSTRING should be set to the connection string of that storage account
Troubleshooting
If your workflow app is not coming up, you can use the Kudu console of the app to check the name resolution and the connectivity. Pls note that you need to connect to kudu console from the vnet if you have enabled private endpoints on the app. Here are some good pointers on debugging connectivity issues.
For example, we can test the private queue endpoint dns resolution for “workflowState” as shown below.
And the connectivity to the private endpoint can be tested as shown below:
Further Reading
This article provides an in-depth detail on different networking options available on App Service platform and Logic Apps preview inherits most of these features given it is running on the App service infrastructure.
Sample App
Here is a set of ARM templates and workflows of a sample of Logic App integrated into a vNET.