Secure Microsoft Fabric with Private Link (Workspace-Level Setup + Architecture)

In the Power BI workspace, users can access reports either from the azure virtual network or from other networks, but when the semantic models are refreshed, the Fabric workspace can use the private network to access lakehouse data in the restricted workspace.

YouTube Video Walkthrough

This runbook accompanies a video walk-through of the process published to my YouTube Channel:

Target outcome

Deploy a restricted Fabric workspace that hosts a lakehouse and is reachable only through an approved Azure VNet, while keeping a second workspace open for semantic models and reports that connect back to the restricted lakehouse through a virtual network data gateway.

How to use this runbook
Work through the phases in order. Do not skip the sequencing around Workspace 1: create it empty, set up the private link, validate name resolution from the VM, deny public access, and only then create the lakehouse.

1. Document control and design summary

At-a-glance design decisions

2. Architecture overview

The solution separates the restricted data plane from the open reporting plane. Data access into Workspace 1 stays on the private path. Report authoring and semantic model operations stay in Workspace 2 and use the gateway when they need to reach the lakehouse.

Target implementation architecture

Figure 1. Restricted Fabric lakehouse workspace connected to an approved Azure VNet, with Workspace 2 remaining open and reaching back through a virtual network data gateway.

3. Prerequisites, access, and values to collect

3.1 Required roles and platform prerequisites

3.2 Portal-ready values to collect before you begin

Naming tip
Choose simple names that make the topology obvious. A common pattern is ws1-restricted-data, ws2-open-reporting, rg-fabric-private-01, vnet-fabric-private-01, pe-fabric-ws1, vm-fabric-admin, and gw-fabric-vnet.

3.3 Suggested subnet plan

3.4 Identity values: how to verify them before you deploy

4. Implementation phases

Use the phases below in order. The easiest operator model is:

1. use your local workstation for Azure portal work,
2. use Azure Bastion to reach the VM,
3. from the VM browser, complete all Fabric work that touches Workspace 1 after the workspace is restricted.

Phase 1. Enable the Fabric tenant networking setting

1. Sign in to the Fabric portal with a Fabric administrator account.
2. Open Settings > Admin portal > Tenant settings.
3. Search for Advanced networking settings.
4. Open Configure workspace-level inbound network rules and set it to Enabled.
5. Select Apply and wait up to 15 minutes for the change to propagate.
6. Leave Configure workspace IP firewall rules enabled unless you also plan to use explicit public IP allow lists.

Operator note
This tenant setting is disabled by default. Without it, you can set up the Azure-side private link resources but you cannot finish the workspace public-access restriction from the Fabric side.

Checkpoint

Phase 2. Create the two Fabric workspaces

1. Create Workspace 1 for the restricted data plane. Assign it to the target Fabric capacity and leave it empty.
2. Create Workspace 2 for the open report and semantic-model plane. Assign it to the same or another Premium-capable capacity that supports the semantic model and gateway workflow.
3. Make sure your implementation identity is a workspace admin on both workspaces.
4. Open each workspace in the browser and capture the workspace ID from the URL after /groups/. Store those IDs in your values table.

Operator note
The restricted workspace must be created empty. This sequencing matters because an existing lakehouse creates a default semantic model, and that can interfere with public-access denial if you create it too early.

Checkpoint

Phase 3. Create the Azure resource group and virtual network

1. In Azure portal, create or open the resource group that will hold the deployment. Recommended name: rg-fabric-private-01.
2. Create the virtual network:
   • Name: vnet-fabric-private-01
   • Address space: 10.70.0.0/21
3. Create these four subnets:
   • snet-vm = 10.70.1.0/24
   • snet-fabric-pe = 10.70.2.0/27
   • snet-vnet-data-gw = 10.70.3.0/27
   • AzureBastionSubnet = 10.70.4.0/26
4. Do not add a NAT gateway or public IP requirement to the VM subnet for this runbook.
5. Save the VNet and confirm all subnets exist.

Operator note
If 10.70.0.0/21 overlaps an existing corporate network, keep the same subnet sizes and shift the block to another unused private range such as 10.71.0.0/21.

Checkpoint

Phase 4. Register the Microsoft.Fabric resource provider if needed

1. In Azure portal, go to Subscriptions > your subscription > Resource providers.
2. Search for Microsoft.Fabric.
3. If this is the first workspace-level private link deployment in the subscription, select Re-register.
4. Wait until the provider registration state returns to Registered.

Operator note
Microsoft specifically calls out re-registration for subscriptions that contain the workspace private link resource and the private endpoint.

Checkpoint

Phase 5. Create the Fabric private link service resource in Azure

1. In Azure portal, search for Deploy a custom template and choose Build your own template in the editor.
2. Paste the ARM template shown in Appendix A.
3. Set the resource name to something meaningful such as pls-fabric-ws1.
4. Enter the Tenant ID and Workspace 1 ID.
5. Before clicking Review + Create, verify the IDs one more time:
   • Tenant ID matches Azure portal > Microsoft Entra ID.
   • Workspace 1 ID matches the GUID after /groups/ in the Workspace 1 URL.
6. Deploy the template to the same resource group. The resource is created as a hidden Microsoft.Fabric/privateLinkServicesForFabric object.
7. Verify the hidden resource exists:
   • Open the resource group.
   • Turn on Show hidden resources.
   • Filter by resource type Microsoft.Fabric/privateLinkServicesForFabric.
8. Optional CLI verification:

az resource list \
  --resource-group rg-fabric-private-01 \
  --resource-type Microsoft.Fabric/privateLinkServicesForFabric \
  -o table

Operator note
This resource is the Azure-side private link service that represents Workspace 1.

Checkpoint

Phase 6. Create the Workspace 1 private endpoint and private DNS zone

1. In Azure portal, open Private endpoints and select Create.
2. On Basics, enter the name, region, and resource group values.
3. On Resource, choose Connect to an Azure resource in my directory.
4. Set Resource type to Microsoft.Fabric/privateLinkServicesForFabric.
5. Select the Fabric private link service resource created for Workspace 1.
6. Set Target subresource to workspace.
7. On the Virtual Network page, choose:
   • Virtual network: vnet-fabric-private-01
   • Subnet: snet-fabric-pe
8. On DNS, enable private DNS integration and choose Create new or select privatelink.fabric.microsoft.com.
9. Create the private endpoint and wait for the provisioning state to complete.

Operator note
Microsoft recommends reserving at least 10 IP addresses per workspace-level private endpoint. Today the service creates five IP addresses per workspace-level private link, so do not undersize this subnet.

Checkpoint

Phase 7. Create the Windows VM jump box

1. Create a Windows Server VM in the snet-vm subnet.
2. Set Public inbound ports to None.
3. Do not assign a public IP address to the VM.
4. Use a local administrator username and a strong password that meets Azure complexity rules.
5. After creation, record the VM name and private IP address.

Operator note
This VM is your admin jump box and private test client. After Workspace 1 is locked down, it becomes the cleanest place to browse the Fabric portal for that workspace.

Checkpoint

Phase 8. Deploy Azure Bastion and connect to the VM

1. Open the VM in Azure portal and choose Connect > Bastion.
2. If Bastion is not yet deployed, select Deploy Bastion.
3. Accept or enter a Bastion name and use a Standard static public IP for the Bastion resource if prompted.
4. Wait for the Bastion deployment to finish, then connect using the VM local administrator credentials.
5. Once connected, open Microsoft Edge in the VM.

Operator note
The public surface is the Bastion host, not the VM. Bastion routes the RDP session to the VM private IP.

Checkpoint

Phase 9. Validate private DNS resolution for Workspace 1 from inside the VNet

1. From the VM, open Command Prompt.
2. Construct the Workspace 1 API FQDN as follows:
   • Start with the Workspace 1 ID.
   • Remove the dashes.
   • Take the first two characters of the dashless Workspace 1 ID.
   • Build the host in this pattern:

{workspaceIdWithoutDashes}.z{firstTwoChars}.w.api.fabric.microsoft.com

1. Example:
   • Workspace ID: cfafbeb1-8037-4d0c-896e-a46fb27ff227
   • Without dashes: cfafbeb180374d0c896ea46fb27ff227
   • First two characters: cf
   • FQDN: cfafbeb180374d0c896ea46fb27ff227.zcf.w.api.fabric.microsoft.com
2. Run nslookup against that FQDN.
3. Confirm the result is a private IP address, not a public IP.
4. Then sign in to the Fabric portal in the VM browser and verify you can reach Workspace 1 while still inside the private path.

nslookup <workspaceIdWithoutDashes>.z<firstTwoChars>.w.api.fabric.microsoft.com

Operator note
Do this validation before you deny public access. It proves the private endpoint and DNS wiring are correct.

Checkpoint

Phase 10. Deny public access to Workspace 1

1. From the Fabric portal, preferably in the VM browser, open Workspace 1.
2. Go to Workspace settings > Inbound networking.
3. Select Allow connections from selected networks and workspace level private links.
4. Apply the change.
5. Allow up to 30 minutes for the public-access restriction to take effect.

Operator note
From this point forward, treat the VM browser as the normal admin path for Workspace 1.

Expected off-network user experience
Users on the wrong network may still see the workspace shell or item list if they already have workspace permissions, but opening supported items such as a notebook can return 403 / API Access Denied. Treat workspace-level private link as an access-enforcement control, not a metadata-concealment feature.

Checkpoint

Phase 11. Create the Workspace 1 lakehouse and a test table

1. Still from the VM browser, open Workspace 1 in the Fabric portal.
2. Create the lakehouse item in Workspace 1.
3. Load at least one test table into the lakehouse so the semantic-model connection has something to read.
4. If you want to mirror Microsoft's sample pattern, you can use Azure Storage Explorer to connect to the OneLake path and upload a small Delta table folder into the Tables area.

Operator note
The important part is not the ingestion method. The important part is that the table lives in Workspace 1 and can be reached through the lakehouse SQL analytics endpoint.

Checkpoint

Phase 12. Prepare the delegated subnet and create the virtual network data gateway

1. In Azure portal, open the snet-vnet-data-gw subnet.
2. Set Subnet delegation to Microsoft.PowerPlatform/vnetaccesslinks.
3. In the Fabric or Power BI portal, open Manage connections and gateways using the gear icon in the upper-right corner:
   • Settings (gear) > Manage connections and gateways
4. If you do not see it there, use the fallback path:
   • Power Platform admin center > Manage > Data (preview)
5. Create a new virtual network data gateway using the VNet and delegated subnet you created.
6. Wait for the gateway to show a healthy state.

Operator note
The gateway must live in the same VNet pattern that can resolve and reach the restricted workspace.

Checkpoint

Phase 13. Create the SQL connection on the gateway

1. In Workspace 1, locate the item with the same name as the lakehouse and type SQL analytics endpoint.
2. Open that SQL analytics endpoint item.
3. Go to Settings > SQL endpoint.
4. Copy the SQL connection string.
5. From that connection string, copy the server host name. Use that value as the Server in the new SQL Server connection.
6. Now open the lakehouse item itself in Workspace 1.
7. Copy the GUID after /lakehouses/ from the browser URL. This is the Lakehouse ID.
8. Open Settings (gear) > Manage connections and gateways.
9. Select New and create a new SQL Server connection on the virtual network data gateway you created in Phase 12.
10. Fill in the connection fields exactly as follows:

1. Sign in with the same identity that can already open the restricted lakehouse and its SQL analytics endpoint.
2. Save the connection.

Operator note
This gateway connection is the bridge that Workspace 2 will use. For this runbook, do not use the OneLake catalog path for the semantic model.

Checkpoint

Phase 14. Create the semantic model and report in Workspace 2

1. Open Workspace 2. You can do this from the VM browser or from your local workstation; using the VM during initial build avoids ambiguity.
2. Create a new Semantic model.
3. Choose Get data and select Azure SQL database so the model connects through the SQL analytics endpoint.
4. Enter the same Server and Database values that worked for the SQL Server connection in Phase 13.
5. Authenticate with Organizational account.
6. Choose Import or DirectQuery according to your requirement.
7. Select the tables to include and complete creation of the semantic model and starter report.

Operator note
At creation time the model might not fully connect until the gateway mapping is finalized. That is expected.

Checkpoint

Phase 15. Bind the semantic model to the gateway connection and test refresh

1. Open the semantic model settings in Workspace 2.
2. Turn on Gateway connections or Gateway and cloud connections, depending on the portal label you see.
3. Select the SQL connection on the virtual network data gateway that points to Workspace 1.
4. Save the setting and refresh the semantic model.
5. Open the report and confirm visuals return data from the restricted lakehouse.

Operator note
If the portal mapping does not light up cleanly, use the documented Get Gateways and BindToGateway APIs shown in Appendix B as the fallback path.

Checkpoint

5. Validation checklist

6. Common pitfalls and troubleshooting

Fast recovery rule
If Workspace 1 setup becomes messy, it is usually faster to delete the private-link resources and the empty restricted workspace and start over than to keep patching an out-of-sequence build.

7. Operational handoff notes

Appendix A. ARM template for the Fabric private link service

Use this template with Azure portal > Deploy a custom template. Replace the placeholder values before deployment.

{
  "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {},
  "resources": [
    {
      "type": "Microsoft.Fabric/privateLinkServicesForFabric",
      "apiVersion": "2024-06-01",
      "name": "<resource-name>",
      "location": "global",
      "properties": {
        "tenantId": "<tenant-id>",
        "workspaceId": "<workspace-id>"
      }
    }
  ]
}

Appendix B. Useful command and API snippets

These are fallback tools for validation and troubleshooting. The main runbook uses the portal wherever possible.

B.1 Workspace FQDN pattern for API / private-resolution tests

{workspaceIdWithoutDashes}.z{firstTwoChars}.w.api.fabric.microsoft.com

Where:

• workspaceIdWithoutDashes = Workspace ID with - removed
• firstTwoChars = first two characters of the dashless Workspace ID

Example:

cfafbeb180374d0c896ea46fb27ff227.zcf.w.api.fabric.microsoft.com

B.2 Private DNS validation from the VM

nslookup <workspaceIdWithoutDashes>.z<firstTwoChars>.w.api.fabric.microsoft.com

B.3 Verify the hidden Fabric private link service resource

az resource list \
  --resource-group <resource-group-name> \
  --resource-type Microsoft.Fabric/privateLinkServicesForFabric \
  -o table

B.4 Get gateway instances

GET https://api.fabric.microsoft.com/v1/gateways

B.5 Workspace network communication policy API

PUT https://api.fabric.microsoft.com/v1/workspaces/{workspaceID}/networking/communicationPolicy
Content-Type: application/json

{
  "inbound": {
    "publicAccessRules": {
      "defaultAction": "Deny"
    }
  }
}

B.6 Notes about semantic-model binding

If the portal does not bind the semantic model cleanly to the VNet gateway connection, use the documented gateway binding APIs from Microsoft Fabric as the fallback path. Keep the same Server, Database, and OAuth2 identity values used in the gateway connection.

Appendix C. Official Microsoft documentation referenced for this runbook

• Enable workspace inbound access protection
• Set up and use workspace-level private links
• Supported scenarios and limitations for workspace-level private links
• About cross-workspace communication
• Access inbound restricted lakehouse data from Power BI by using a virtual network gateway
• Use virtual network data gateway and data sources in Power BI
• What is Azure Bastion?
• About Azure Bastion configuration settings

Reference URLs

Supported scenarios for workspace private links - Microsoft Fabric

Find information and links for supported and unsupported workspace-level private link scenarios.

Microsoft Learnmsmimart

• https://learn.microsoft.com/en-us/fabric/security/security-workspace-enable-inbound-access-protection
• https://learn.microsoft.com/en-us/fabric/security/security-workspace-level-private-links-set-up
• https://learn.microsoft.com/en-us/fabric/security/security-workspace-level-private-links-support
• https://learn.microsoft.com/en-us/fabric/security/security-cross-workspace-communication
• https://learn.microsoft.com/en-us/fabric/security/security-workspace-private-links-example-power-bi-virtual-network
• https://learn.microsoft.com/en-us/data-integration/vnet/use-data-gateways-sources-power-bi
• https://learn.microsoft.com/en-us/azure/bastion/bastion-overview
• https://learn.microsoft.com/en-us/azure/bastion/configuration-settings