Forum Discussion
Workspace IP Firewall: Expected Behavior for Cross-Workspace API Calls?
We are evaluating Workspace IP firewall rules and noticed that cross-workspace API calls may be blocked when the source IP is not included in the workspace allowlist.
Example:
Workspace A uses its Workspace Identity to call Fabric APIs.
Workspace B is protected by Workspace IP firewall rules.
Workspace A has the required permissions on Workspace B.
The API call fails because the source IP is not allowed.
Is this expected behavior?
If so, what is the recommended approach for secure Fabric-to-Fabric API communication between workspaces protected by Workspace IP firewall rules?
More specifically, are Workspace Identities and Service Principals expected to work in this scenario, or are they also subject to the same IP-based restrictions? Workspace IP firewall rules restrict incoming access based on approved IP addresses.
Additionally, is Microsoft currently evaluating any enhancements in this area, such as support for trusted Workspace Identities or Service Principals for cross-workspace API scenarios?
Hi wolfee,
Yes, the behaviour is expected. The workspace IP firewall is evaluated at the network layer before the request reaches identity and RBAC evaluation, so having the correct workspace identity or service-principal permissions on Workspace B is not enough by itself.
Microsoft now documents this scenario in its cross-workspace communication guidance. When the target workspace restricts inbound public access, the supported options are:
- Create a managed private endpoint from Workspace A to Workspace B and have the target workspace’s Private Link service owner approve the connection.
- Route the connection through a virtual network or on-premises data gateway that has private connectivity to Workspace B.
The managed private endpoint option is currently supported only for specific cross-workspace scenarios, including shortcuts, notebooks accessing Lakehouses, pipelines accessing notebooks, and Eventstreams writing to Lakehouses. The exact API or item operation therefore matters. Microsoft lists the currently supported combinations in its workspace-level private link limitations.
Workspace identities and service principals are still used for authentication and authorization, but they are not exempt from the target workspace’s inbound network controls. I would therefore avoid maintaining broad Fabric service-IP allowlists, especially because those addresses can change and do not provide workload-level trust.
For a supported scenario, my preferred design would be:
Workspace A identity or service principal → managed private endpoint → Workspace B → RBAC validation
If the API call is not one of the currently supported managed-private-endpoint scenarios, the practical alternatives are a gateway-backed route, moving the orchestration into the protected workspace, or keeping public access enabled with a tightly controlled IP allowlist.
I hope this helps clarify the distinction between network access and identity permissions. The key next detail would be which Fabric API or item in Workspace B is being called, because that determines whether the managed private endpoint route is currently supported.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
3 Replies
- tayloramy
Super User
Hi wolfee,
This is an area that leaves something to be desired.
Right now, as far as I know, there's no wornaround here other than disabling the the firewall rules, or adding all of the fabric service IPs to your allowlist, which is hundreds of IPs and changes often, making that an unsustainable option.
I would love to see a configuration setting to allow traffic from Fabric itself as a single checkbox, but currently we don't have that.
- ShivekMaharaj
Memorable Member
Hi wolfee,
Yes, the behaviour is expected. The workspace IP firewall is evaluated at the network layer before the request reaches identity and RBAC evaluation, so having the correct workspace identity or service-principal permissions on Workspace B is not enough by itself.
Microsoft now documents this scenario in its cross-workspace communication guidance. When the target workspace restricts inbound public access, the supported options are:
- Create a managed private endpoint from Workspace A to Workspace B and have the target workspace’s Private Link service owner approve the connection.
- Route the connection through a virtual network or on-premises data gateway that has private connectivity to Workspace B.
The managed private endpoint option is currently supported only for specific cross-workspace scenarios, including shortcuts, notebooks accessing Lakehouses, pipelines accessing notebooks, and Eventstreams writing to Lakehouses. The exact API or item operation therefore matters. Microsoft lists the currently supported combinations in its workspace-level private link limitations.
Workspace identities and service principals are still used for authentication and authorization, but they are not exempt from the target workspace’s inbound network controls. I would therefore avoid maintaining broad Fabric service-IP allowlists, especially because those addresses can change and do not provide workload-level trust.
For a supported scenario, my preferred design would be:
Workspace A identity or service principal → managed private endpoint → Workspace B → RBAC validation
If the API call is not one of the currently supported managed-private-endpoint scenarios, the practical alternatives are a gateway-backed route, moving the orchestration into the protected workspace, or keeping public access enabled with a tightly controlled IP allowlist.
I hope this helps clarify the distinction between network access and identity permissions. The key next detail would be which Fabric API or item in Workspace B is being called, because that determines whether the managed private endpoint route is currently supported.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
v-sathmakuriCommunity Support
Hi wolfee ,
Thank you for reaching out to fabric community.
Could you review the suggestion provided above and let us know if you have any additional questions, we are happy to address.
Thanks!!
