Direct Lake Support for Private Workspace FQDN Connections in VNet-Restricted Microsoft Fabric
Hi Microsoft Team, We are seeking clarification on Direct Lake support for private workspace connections in Microsoft Fabric. From our understanding, Direct Lake semantic models should be able to connect to OneLake-backed data sources. We are specifically investigating whether Direct Lake supports connections using privately resolvable workspace fully qualified domain names (FQDN) in a VNet-restricted architecture. Current Infrastructure Setup: Private Link configured in VNet-restricted Gold Workspace Managed private endpoint enabled in Reporting Workspace Inbound networking traffic restricted in Gold Workspace Currently operational: Direct Lake connection using public OneLake URL (onelake.dfs.fabric.microsoft.com) routed through managed private endpoints What We Tested: Registered a warehouse in a VNet-restricted Gold Workspace Created a new connection using workspace FQDN with service principal authentication in the public Reporting Workspace Successfully validated the connection (connection test passed) Attempted to bind this FQDN connection to a Direct Lake semantic model Binding operation failed with error Error Observed: "Direct Lake On OneLake requires a valid OneLake data source. Please verify and fix the data source definitions." Questions: Is Direct Lake architecturally designed to work only with public OneLake URIs (onelake.dfs.fabric.microsoft.com), or is there a supported way to use Direct Lake with privately resolvable workspace FQDNs? Does Direct Lake support connections through private workspace endpoints in a VNet-restricted scenario without reverting to the public OneLake URL? If private workspace FQDNs are not currently supported for Direct Lake, are there any planned features or documented workarounds for this scenario? We would appreciate any guidance on supported connectivity patterns or known limitations for this architecture. Thank you.Microsoft Fabric Security Policies: How They Strengthen Data Security and Governance?
In today’s data-driven world, governance isn’t just about compliance — it’s about enabling trust, consistency, and scale. As organizations adopt Microsoft Fabric to unify their analytics, the challenge of managing who can do what, where, and under which conditions become critical. That’s where Microsoft Fabric policies step in. Think of them as the rulebooks that let administrators define guardrails across workspaces, security groups, and sensitivity labels. Instead of relying on manual oversight, policies provide a centralized, automated way to enforce governance — ensuring that innovation doesn’t come at the cost of control. In this blog will walk you through the key concepts, the entry points for creating and activating policies, and the end-to-end lifecycle that makes governance in Fabric both powerful and practical. Prerequisites: 1) A Valid Fabric Trail / Capacity License 2) A Fabric workspace assigned to a Capacity/Fabric Trail. 3) Proper admin role to activate the policy a) Fabric administrator: Can create and activate policies for tenant-scope policies. b) Capacity administrator: Can create and activate policies for capacity-scope policies. 4) Contributor, Member, or Admin access to the workspace so that you can create a policy item type. 5) The Policies tenant setting is enabled in Admin settings 6) Valid Security groups in AAD. Step 1: Enable the Policies feature in the admin settings Go to fabric admin settings, search for polices(preview) and enable the setting and click on apply. Step 2: Creating Policy item Create a workspace ‘Fabric-Polices-Ws’ which was assigned to ‘Fabric Trail’ and I’m (SI Babu) who’s the capacity admin. Make sure this should be a secured, admin-managed workspace to store policies. Click on ‘New Item’ and select ‘Policy set (preview)’ under ‘Govern data’ In New policy set dialog, enter a unique and descriptive Name ‘Capacity_PolicySet_1’ for the policy set and choose ‘ A capacity’ under policy scope then Click on ‘Create’ Create another policy set ‘Tenent_Policy_set2’ and choose ‘ Fabric Tenant’ under policy scope then Click on ‘Create’ Two policy sets are created. Step 3: Activating the Policy set Open Capacity policy set and select the ‘Active’ from Status Select the capacity and click on ‘Assign + activate’ Policy activated successfully Open Tenant policy set and select the ‘Active’ from Status Click on ‘Activate’ the policy Policy activated successfully Step 4: Create / Add Policy Rules(Capacity Policy) Click on ‘OneLake catalog’ Click on ‘Govern’ à‘Polices(preview)’ àCapacitiesàExpand the ‘Users can create items’ and select ‘Advanced’ Here, Select Allowed, Blocked, or Advanced (Set by user) to change the policy behavior. If you select Advanced, the rules configuration is enabled. Add a new rule with good name, description and Select ‘item type’ in Condition type, operator is ‘Is any of’ the select ‘Lakehouse’ and ‘Dataflow gen2’ then click on ‘+Add condition’ Choose ‘workspace’ in condition type, operator is ‘Is any of’ selected two workspaces gen2’ then click on ‘+Add condition’ Choose ‘Security group’ in condition type, operator is ‘Is any of’ selected my ‘Data Analyst’ AD group. Click on Apply Note: In this Data Analyst group we have three developers are there Click on “Save’ Now Policy successfully added Step 5: Validate policy enforcement (Capacity Policy) Added ‘Data Analyst’ AD group to both the workspaces ‘FabricRTI Training’ & ‘PowerBI-Demo-WS’ Now I was opened another window with account(SP Babu) who’s part of AD group & you can see two workspaces Create a ‘Notebook’ Now when I click on “Create” it’s throwing an error as you seen in below screenshot. Means it enforced a policy Again, When I was trying to create ‘Warehouse’ it’s throwing the same error. I (SP Babu) was able to create ‘DataFlowGen2’. Admin enforced to create only this item I (SP Babu) was able to create ‘Lakehouse’. Admin enforced to create only this item Step 6: Create / Add Policy Rules(Tenant Policy) Create another policy should be at tenant level to restrict workspace Outbound access protection and inbound network rules and click ‘add condition’ Add “Security group’ as I have IT Infra Team and click Apply Note: In this IT Infra Team group we have three resources are there Security policy created successfully Step 7: Validate policy enforcement (Tenant Policy) Now SP Babu unable to edit ‘Outbound access’ it’s showing ‘This setting is managed by a tenant policy.’ SP Babu unable to edit ‘Inbound access’ it’s showing ‘This setting is managed by a tenant policy.’ You can deactivate or replace an active policy set from the workspace where the policy set is stored. Only an administrator of the policy set's admin scope can deactivate or replace it. Best practices for creating a policy: Use a secured, admin-managed workspace to store policies. Store all policies for the admin scopes managed by the same administrator or admin team in the same workspace. This approach provides one location for tenant- and capacity-scoped policies and simplifies access management, discovery, and lifecycle management. Use clear policy set and rule names that identify the admin scope and purpose. Use test users who are members and non-members of the configured security groups to validate both allow and deny outcomes before broader rollout. Limitations as of now: Fabric policies aren't currently supported in the following capacity regions: West Europe, North Europe, and West US. We can currently create policy sets only from the item creation experience in a workspace. Only workspaces assigned to a Fabric capacity can store policy sets. We can't change a policy set's admin scope after creation. Only one policy set can be active for an admin scope at a time. Policy and tenant-setting changes can take time to propagate. Conditions support Any of and None of in the current preview. We can't activate a policy set through Git. So, start small with pilot policies, monitor audit logs for adoption and Communicate changes to workspace owners Conclusion Microsoft Fabric Policies are still in preview, but they signal a future where governance is not a blocker — it’s an enabler of responsible innovation. Happy learning! — Inturi Suparna Babu [LinkedIn]Workspace and github
Hello, in this time, I try to configure the syncronized worskpace and github, in the workspace the role is admin, and when I click in soruce contro, it show me a message: What actually means... Am I have to connect with github account? how? I'am not the owner of the repo in github.. Thanks in advance.
Controlled "Semantic Model Execute Queries" REST API Access for Fabric Users
We want to enable the executeQueries endpoint for a large audience of users so that an application can execute DAX queries against a directlake model (with SSO enabled) on their behalf. Enabling this endpoint poses a security risk because it allows users to access Fabric via unapproved tools. (Some are safe and helpful, but this can't be guaranteed.) The relevant tenant setting ("Semantic Model Execute Queries REST API") can be scoped to security groups, but it cannot limit incoming traffic to a specific source (our trusted application). Fabric provides controls to limit inbound traffic - IP allow-lists, private links at the workspace level, conditional entra access policies, etc. We have reviewed the options on this page: About inbound access protection in Fabric - Microsoft Fabric | Microsoft Learn. Semantic models are not supported for most of these solutions (private links, for example), and even if they were, they seem like they would treat API access and portal access the same. Any setting that sufficiently restricts traffic to the API endpoint would also lock users out of the Fabric portal itself (or unnecessarily restrict data in the portal). Have we missed anything? Is there a way to conditionally allow API access from specific sources for security groups without negatively impacting users by applying those same restrictions to standard portal access?
OLS vs RLS vs CLS: understanding the scope of application
Hi, I need to understand better the scope of application about the Object Level Security, the Row Level Security and the Columns Level Security. I know that: the OLS concerns both a lakehouse or warehouse table/view and a semantic model table, the RLS is applicable to a lakehouse or warehouse table/view as well as a semantic model table, the CLS regards both a lakehouse or warehouse table/view and a semantic model table. is all this right or not? Talking about OLS, a warehouse table is an object to protect as well as a semantic model table. Any helps to me to understand better the application scope of these security levels? Thanks
Restrict inbound connections to fabric workspace
Hi, the customer wants to restrict the production workspace inbound access and allow only access from their corporate network or VPN. This can be done using the Workspace level Firewall https://learn.microsoft.com/en-us/fabric/security/security-workspace-level-firewall-overview But we cannot progress with this due to 2 reasons: We are using fabric link from dataverse to source data to fabric - which apparently is not supported when a workspace has any inbound restrictions https://learn.microsoft.com/en-us/power-apps/maker/data-platform/fabric-link-faq#what-network-settings-are-required-in-microsoft-fabric-to-create-a-link-to-fabric We also plan on using the deployment pipelines which also dont support workspaces with inbound access restrictions https://learn.microsoft.com/en-us/fabric/security/security-workspace-level-private-links-support?tabs=fabric-portal-1%2Cfabric-portal-2%2Cfabric-portal-15%2Cfabric-portal-4%2Cfabric-portal-5%2Cfabric-portal-6%2Cfabric-portal-7%2Cfabric-portal-8%2Cfabric-portal-9%2Cfabric-portal-10%2Cfabric-portal-11%2Cfabric-portal-12%2Cfabric-portal-13%2Cfabric-portal-14#management-options-for-supported-item-types If this is the case, what are the options for the security implementation here? There is conditional access policy restrictions, but I think its applicable at Fabric level and not only workspace level? https://learn.microsoft.com/en-us/fabric/security/security-conditional-access Any insights would be greatly appreciated.
Cross-Tenant VNet Peering with VNet Data Gateway
I am considering the following architecture: Microsoft Fabric → VNet Data Gateway → Tenant A VNet → Cross-Tenant VNet Peering → Tenant B VNet → Private Endpoint → Azure Database for PostgreSQL Flexible Server The VNet Data Gateway is deployed in the same tenant as Microsoft Fabric (Tenant A). PostgreSQL Flexible Server and its Private Endpoint are in Tenant B. Is this architecture supported by Microsoft Fabric? I am especially interested in: Private DNS configuration across the two VNets Cross-tenant VNet peering configuration VNet Data Gateway configuration PostgreSQL Private Endpoint configuration Has anyone implemented this architecture in a PoC or production environment? If so, I would appreciate any configuration examples or screenshots from Azure Portal or Fabric Portal.
