Secure traffic between Standard logic apps and Azure virtual networks using private endpoints

Alt
08/09/2024

Applies to: Azure Logic Apps (Standard)

To securely and privately communicate between your workflow in a Standard logic app and an Azure virtual network, you can set up private endpoints for inbound traffic and use virtual network integration for outbound traffic.

A private endpoint is a network interface that privately and securely connects to a service powered by Azure Private Link. This service can be an Azure service such as Azure Logic Apps, Azure Storage, Azure Cosmos DB, SQL, or your own Private Link Service. The private endpoint uses a private IP address from your virtual network, which effectively brings the service into your virtual network.

This article shows how to set up access through private endpoints for inbound traffic and virtual network integration for outbound traffic.

For more information, review the following documentation:

Prerequisites

A new or existing Azure virtual network that includes a subnet without any delegations. This subnet is used to deploy and allocate private IP addresses from the virtual network.

For more information, review the following documentation:

Install or use a tool that can send HTTP requests to test your solution, for example:
Caution

For scenarios where you have sensitive data, such as credentials, secrets, access tokens, API keys, and other similar information, make sure to use a tool that protects your data with the necessary security features, works offline or locally, doesn't sync your data to the cloud, and doesn't require that you sign in to an online account. This way, you reduce the risk around exposing sensitive data to the public.

Set up inbound traffic through private endpoints

To secure inbound traffic to your workflow, complete these high-level steps:

Start your workflow with a built-in trigger that can receive and handle inbound requests, such as the Request trigger or the HTTP + Webhook trigger. This trigger sets up your workflow with a callable endpoint.
Add a private endpoint for your logic app resource to your virtual network.
Make test calls to check access to the endpoint. To call your logic app workflow after you set up this endpoint, you must be connected to the virtual network.

Considerations for inbound traffic through private endpoints

If accessed from outside your virtual network, monitoring view can't access the inputs and outputs from triggers and actions.
Managed API webhook triggers (push triggers) and actions won't work because they run in the public cloud and can't call into your private network. They require a public endpoint to receive calls. For example, such triggers include the Dataverse trigger and the Event Grid trigger.
If you use the Office 365 Outlook trigger, the workflow is triggered only hourly.
Deployment from Visual Studio Code or Azure CLI works only from inside the virtual network. You can use the Deployment Center to link your logic app to a GitHub repo. You can then use Azure infrastructure to build and deploy your code.

For GitHub integration to work, remove the WEBSITE_RUN_FROM_PACKAGE setting from your logic app or set the value to 0.
Enabling Private Link doesn't affect outbound traffic, which still flows through the App Service infrastructure.

Prerequisites for inbound traffic through private endpoints

Along with the virtual network setup in the top-level prerequisites, you need to have a new or existing Standard logic app workflow that starts with a built-in trigger that can receive requests.

For example, the Request trigger creates an endpoint on your workflow that can receive and handle inbound requests from other callers, including workflows. This endpoint provides a URL that you can use to call and trigger the workflow. For this example, the steps continue with the Request trigger.

For more information, review Receive and respond to inbound HTTP requests using Azure Logic Apps.

Create the workflow

If you haven't already, create a single-tenant based logic app, and a blank workflow.
After the designer opens, add the Request trigger as the first step in your workflow.
Based on your scenario requirements, add other actions that you want to run in your workflow.
When you're done, save your workflow.

For more information, review Create single-tenant logic app workflows in Azure Logic Apps.

Copy the endpoint URL

On the workflow menu, select Overview.
On the Overview page, copy and save the Workflow URL for later use.
To test the URL and trigger the workflow, send an HTTP request to the URL by using your HTTP request tool and its instructions.

Set up private endpoint connection

On the logic app resource menu, under Settings, select Networking.
On the Networking page, in the Inbound traffic configuration section, select the link next to Private endpoints.
On the Private Endpoint connections page, select Add > Express or Advanced.

For more information about the Advanced option, see Create a private endpoint.
On the Add Private Endpoint pane, provide the requested information about the endpoint.

For more information, review Private Endpoint properties.
After Azure successfully provisions the private endpoint, try again to call the workflow URL.

This time, you get an expected 403 Forbidden error, which is means that the private endpoint is set up and works correctly.
To make sure the connection is working correctly, create a virtual machine in the same virtual network that has the private endpoint, and try calling the logic app workflow.

Set up outbound traffic using virtual network integration

To secure outbound traffic from your logic app, you can integrate your logic app with a virtual network. First, create and test an example workflow. You can then set up virtual network integration.

Considerations for outbound traffic through virtual network integration

Setting up virtual network integration affects only outbound traffic. To secure inbound traffic, which continues to use the App Service shared endpoint, review Set up inbound traffic through private endpoints.
You can't change the subnet size after assignment, so use a subnet that's large enough to accommodate the scale that your app might reach. To avoid any issues with subnet capacity, use a /26 subnet with 64 addresses. If you create the subnet for virtual network integration with the Azure portal, you must use /27 as the minimum subnet size.

For the Azure Logic Apps runtime to work, you need to have an uninterrupted connection to the backend storage. If the backend storage is exposed to the virtual network through a private endpoint, make sure that the following ports are open:

Source port	Destination port	Source	Destination	Protocol	Purpose
*	443	Subnet integrated with Standard logic app	Storage account	TCP	Storage account
*	445	Subnet integrated with Standard logic app	Storage account	TCP	Server Message Block (SMB) File Share

For Azure-hosted managed connectors to work, you need to have an uninterrupted connection to the managed API service. With virtual network integration, make sure that no firewall or network security policy blocks these connections. If your virtual network uses a network security group (NSG), user-defined route table (UDR), or a firewall, make sure that the virtual network allows outbound connections to all managed connector IP addresses in the corresponding region. Otherwise, Azure-managed connectors won't work.