Securing Inbound Connectivity — Setting up Private Link in Fabric with Terraform

Aitor Murguzur
4 min readJul 10, 2024

--

In the previous blog post, we detailed how to securely access Azure resources from Fabric Spark using managed private endpoints (outbound connectivity).

This blog post is focused on inbound connectivity, settting up a Private Link with Terraform to securely access Fabric resources. For more information, refer to protect inbound traffic in Fabric.

Why Private Link? Private links provide secure access for data traffic in Fabric. Azure Private Link and Azure private endpoints are used to send data traffic privately using Microsoft’s backbone network infrastructure instead of going across the internet.

There are two Fabric tenant settings to control inbound connectivity:

  • Azure Private Link: allows people to use a Private Link to access your Fabric tenant. You need to finish the set-up process in Azure.
  • Block Public Internet Access: blocks access to your Fabric tenant via the public internet. This means people who don’t have access to the Private Link won’t be able to get in.

In this blog, we’ll focus on the former, setting up the required infrastructured on Azure using Terraform. Review the considerations and limitations section before enabling both tenant settings.

> For a quick look at the code, go straight to the GitHub repository.

This blog is divided into two parts:

  1. Setting up the infrastructure: I’ll show you how to deploy a Private Link service, configure the required private DNS zones and networking, and set up a jumphost using Terraform.
  2. Accessing Fabric resources securely: log in into the jumphost to test Fabric connectivity and resolve private IPs.

Deploying resources on Azure

We’re going to use Terraform to deploy the required infrastructure and set up a Private Link.

Prerequisites

Once the Azure Private Link is enabled in Fabric, we’ll create a virtual network, private endpoint, and jumphost to securely access Fabric. The below-listed Azure resources will be deployed using Terraform, including the necessary private endpoint and DNS zones.


+--------------------+----------------------------------------------------+
| Resource | Comment |
+--------------------+----------------------------------------------------+
| Resource Group | One for deployed resources |
| Virtual Network | 10.0.0.0/16 by default |
| Subnet | default (10.0.1.0/24) and bastion (10.0.10.0/27) |
| PL Service | privateLinkServicesForPowerBI |
| Private Endpoint | Subresource name = tenant |
| Private DNS Zones | Three private DNS zones |
| Virtual Machine | Jumphost, includes Bastion |
+--------------------+----------------------------------------------------+

Clone this repository, and execute the commands below to deploy the required infrastructure:

# Initialize the Terraform configuration by running
terraform init

# Then, apply the configuration using
terraform apply -auto-approve

After Terraform deployment, you’ll see something like this:

Testing the connectivity

With all resources deployed, we can access Fabric privately from the jumphost and test connectivity. Log into your jumphost, open the Windows command prompt, and resolve IPs. Here are a few examples:

  • nslookup app.fabric.microsoft.com
  • nslookup onelake.dfs.fabric.microsoft.com
  • nslookup <your-sql-endpoint>

You’ll notice that private IPs are resolved, this is the expected result.

After testing Private Link connectivity with Fabric, you can optionally block public access to Fabric using Block Public Internet Access tenant setting. Note that disabling public access imposes certain constraints on accessing Fabric services. See the full list of limitations and considerations when enabling Azure Private Link and Block Public Internet Access here.

In this mini-series of security blog posts, we’ve explored using Private Link for inbound connectivity and managed private endpoints from Fabric Spark for outbound connectivity, with all Azure infrastructure deployed using Terraform. Private Link can also facilitate outbound connectivity, especially for Azure resources that lack private endpoints.

For instance, it can provide private connectivity to Snowflake, ensuring access through a private IP address. This directs network traffic to the Snowflake virtual network via the Microsoft backbone, bypassing the public internet.

While Snowflake serves as an example, the target system could be any other. Although this blog post doesn’t cover using Private Link for outbound connectivity, I am sharing a few related references below.

Thanks Santhosh for his contributions and review.

--

--

Aitor Murguzur
Aitor Murguzur

Written by Aitor Murguzur

All things data. Principal PM @Microsoft. PhD in Comp Sci. All views are my own. https://www.linkedin.com/in/murggu/

No responses yet