network-best-practices

Private Networking for Microsoft Fabric

When deploying Microsoft Fabric in enterprise environments, private networking considerations are essential for protecting sensitive data, meeting compliance goals, and aligning with Zero Trust principles. Microsoft Fabric builds on top of OneLake and Azure PaaS services, which means it inherits many Azure networking principles and best practices. This section expands on key best practices for securing and optimizing Fabric networking, structured around the Cloud Adoption Framework (CAF) principles.

Use Strong Network Controls for Fabric

Microsoft Fabric relies heavily on Azure networking infrastructure, including Virtual Networks (VNets), Private Endpoints, and ExpressRoute. Because Fabric accesses OneLake and other PaaS services, it is critical to apply strong network controls consistent with Azure best practices:

Centralized Virtual Network Management: Use centralized VNets to simplify IP address management and governance. This helps maintain consistent policies and reduces configuration drift.
IP Address Management (IPAM): Plan and allocate IP address ranges carefully to avoid conflicts, especially when integrating with on-premises networks via VPN or ExpressRoute.
Network Security Group (NSG) Governance: Apply NSGs consistently across subnets hosting Fabric workloads to enforce inbound and outbound traffic rules.
ExpressRoute and Private Endpoints: Use ExpressRoute private peering or Azure Private Link to ensure traffic between Fabric workloads and OneLake remains on the Microsoft backbone, avoiding exposure to the public internet.

By leveraging these controls, organizations can maintain a secure and manageable network posture for Fabric deployments.

Logically Segment Subnets for Fabric Access Patterns

Logical segmentation of subnets helps isolate different Fabric components and control traffic flows effectively. For example:

Place Fabric services such as Notebooks, Pipelines, and Warehouses into dedicated subnets, especially when integrating with services like Azure Synapse or custom Spark clusters.
Use NSGs to control access between these subnets and restrict traffic to only necessary ports and protocols.

Example NSG rule to allow HTTPS traffic from a trusted subnet to OneLake endpoint subnet:

nsgRules:
  - name: Allow-Internal-Onelake
    direction: Inbound
    priority: 100
    access: Allow
    protocol: TCP
    sourceAddressPrefix: VirtualNetwork
    destinationPortRange: 443

This rule permits secure HTTPS traffic within the virtual network while blocking unauthorized access.

Adopt a Zero Trust Approach in Fabric Networking

Fabric networking should align with Zero Trust principles, minimizing implicit trust and enforcing strict access controls:

Conditional Access Integration: Combine Azure Active Directory Conditional Access policies with Fabric services to enforce multi-factor authentication, device compliance, and location-based restrictions.
Service Endpoints and Private Link: Use Azure service endpoints along with Private Link to restrict access to Fabric resources and OneLake storage accounts, reducing the blast radius in case of compromise.
Least Privilege Access: Limit network access to only those subnets and users that require it, continuously reviewing and updating policies.

This approach reduces attack surfaces and improves overall security posture.

Control Routing Behavior for Data Egress

In some scenarios, controlling routing behavior is essential to ensure traffic flows through security appliances or specific network paths:

User-Defined Routes (UDRs): Configure UDRs to direct traffic from Fabric subnets through Azure Firewall, Network Virtual Appliances (NVAs), or on-premises devices.
Example Route Table:

routeTable:
  - name: route-to-firewall
    addressPrefix: 0.0.0.0/0
    nextHopType: VirtualAppliance
    nextHopIpAddress: 10.0.0.4

This route forces all outbound traffic to flow through an NVA at IP 10.0.0.4, enabling inspection and logging.

Proper routing ensures compliance with organizational security policies and helps detect anomalous traffic.

Secure Fabric Resources to Only Your Virtual Networks

Azure Private Link is essential for securing OneLake and other Fabric resources:

Private Endpoint Access: Configure Private Endpoints for OneLake to restrict access to your VNets, preventing exposure to the public internet.
Private DNS Zones: Use private DNS zones (e.g., privatelink.dfs.core.windows.net) to resolve service endpoints internally. This avoids leaking DNS queries to public resolvers.
Limitations: Some Azure regions may have limited support for Private Link with Fabric services. Always consult the latest Azure documentation for regional availability.

Note: Placeholder for Azure regions and their current support status for Fabric Private Link.

Can Fabric Operate Without Public IPs?

Is it best practice to run Fabric without public IPs?

Pros	Cons
Minimizes public internet exposure	Some Power BI service components require outbound connectivity
Aligns with strict compliance and regulatory requirements	Certain connectors and third-party visuals may fail without internet access
Reduces attack surface	Diagnostics and support may be limited or more complex

Power BI tenants and Fabric services often rely on limited outbound internet access for metadata, refresh, and diagnostics. Completely disabling public IPs can introduce operational challenges.

Recommendation: Adopt a hybrid model that restricts most traffic to private networking while allowing necessary outbound flows for Power BI and Fabric services.

Use Network Appliances and DDoS Protection for Perimeter Defense

For enhanced perimeter security, consider deploying:

Azure Firewall or Third-Party NGFWs: Inspect and filter traffic to and from Fabric workloads, especially when integrating with on-premises networks.
Traffic Inspection for OneLake Access: Use firewall policies to monitor and control traffic to OneLake endpoints.
Azure DDoS Protection: Protect public endpoints and VNets from volumetric and protocol attacks.

These appliances provide layered defense and improve threat detection capabilities.

Fabric in Hybrid Networking Scenarios

When integrating Fabric with on-premises or multi-cloud environments:

Use ExpressRoute private peering to route traffic securely over Microsoft’s backbone.
Ensure authentication fallbacks are configured so that identity services can validate users even if network connectivity shifts.
Understand identity implications when routing traffic through hybrid paths, as latency or network restrictions may affect token validation and service availability.

Hybrid networking enables seamless access to Fabric resources while maintaining security and performance.

DNS and NSG Integration – Detailed Guidance

Proper DNS and NSG configuration is critical for private endpoint resolution and security:

dnsZones:
  - name: privatelink.dfs.core.windows.net
    records:
      - name: onelake
        ip: 10.1.2.4
        ttl: 3600

TTL (Time To Live): Controls how long DNS records are cached. Adjust TTL based on how frequently IPs might change.
A vs. CNAME Records: Use A records for static IP addresses; CNAMEs can alias to other DNS names but may introduce resolution dependencies.
Static IPs: Prefer static IP allocation for private endpoints to ensure consistent DNS resolution.

NSGs should be applied at the subnet level to restrict traffic flows to only authorized sources and destinations.

Monitoring and Network Analytics for Fabric

Enable comprehensive monitoring to maintain visibility into Fabric network health:

Diagnostic Settings: Enable diagnostics on private endpoints to capture logs and metrics.
Azure Monitor & Network Watcher: Use these tools to analyze traffic flows, detect anomalies, and troubleshoot issues.
Microsoft Defender for Cloud: Provides threat detection and recommendations specific to network security.

Proactive monitoring helps detect and mitigate security incidents early.

Private Network Access for Fabric Workspaces

Microsoft Fabric workspaces and workloads (such as Lakehouses, Warehouses, Notebooks, Pipelines, etc.) are built on top of Microsoft OneLake and Azure PaaS services. As such, Microsoft Fabric environments can benefit from Azure Private Link, restricting access to Fabric endpoints to private networks only.

Best practice: Use Private Link where supported to limit traffic exposure.

Why: This enhances security by ensuring that traffic between Fabric workloads and storage endpoints (OneLake, ADLS Gen2, etc.) does not traverse the public internet.

How: Currently, OneLake endpoints can be accessed via private endpoints similar to Azure Data Lake Storage. When configured properly, Fabric consumers can access OneLake via the Azure backbone.

az network private-endpoint create \
  --name pe-onelake \
  --resource-group rg-fabric \
  --vnet-name vnet-fabric \
  --subnet subnet-data \
  --private-connection-resource-id <OneLake Resource ID> \
  --group-id dfs \
  --connection-name onelake-pe-connection

Is Fabric Usable Without Public IP?

In theory, yes. Fabric workloads can be configured to run entirely over private endpoints by routing traffic over ExpressRoute or site-to-site VPN and disabling public access to underlying storage accounts and Power BI tenants.

However, in practice this setup is very restrictive:

Power BI service components (for example, tenant metadata, dataset refresh services) often still require limited outbound connectivity.
Some connectors and third-party visuals still rely on public internet access.
Support for Private Link is currently evolving and may not yet cover all Fabric services (e.g. Real-Time Analytics).

Conclusion: While it is technically possible to operate Microsoft Fabric without a public IP footprint, this approach may introduce more complexity than value unless justified by strong compliance or regulatory needs.

Private DNS and NSG Integration

When deploying private endpoints, don’t forget to configure:

Private DNS zones for resolution (e.g. privatelink.dfs.core.windows.net)
Network Security Groups (NSGs) to restrict access on a per-subnet basis.

dnsZones:
  - name: privatelink.dfs.core.windows.net
    records:
      - name: onelake
        ip: 10.1.2.4
        ttl: 3600

nsgRules:
  - name: Allow-Internal-Onelake
    direction: Inbound
    priority: 100
    access: Allow
    protocol: TCP
    sourceAddressPrefix: VirtualNetwork
    destinationPortRange: 443

Summary

Use private endpoints for Microsoft Fabric’s OneLake access where possible. Consider a hybrid model that restricts most traffic to private networking but allows necessary outbound flows for the Power BI service to function properly.

Ongoing monitoring and support from Microsoft’s documentation is recommended as capabilities for Fabric’s private networking evolve.

Private Networking for Microsoft Fabric​

Use Strong Network Controls for Fabric​

Logically Segment Subnets for Fabric Access Patterns​

Adopt a Zero Trust Approach in Fabric Networking​

Control Routing Behavior for Data Egress​

Secure Fabric Resources to Only Your Virtual Networks​

Can Fabric Operate Without Public IPs?​

Use Network Appliances and DDoS Protection for Perimeter Defense​

Fabric in Hybrid Networking Scenarios​

DNS and NSG Integration – Detailed Guidance​

Monitoring and Network Analytics for Fabric​

Private Network Access for Fabric Workspaces​

Is Fabric Usable Without Public IP?​

Private DNS and NSG Integration​

Summary​

Contributors