Lakehouse SQL endpoint access

[Manu002]

Hi Experts,

I'm facing a problem. I give access to only one lakehouse in a workspace to a user via SQL Endpoint. Unexpectedly, That user has access also to other lakehouse in that workspace. I verified it using SSMS. I'm sure that the user doesn't have any role at workspace level.

I don't see a "ReadData" permission while giving access to the user. Is it due to I'm not a admin of workspace. I'm only a member of that workspace. Attacehed the SS FYR.

Additionally, both lakehouse in that workspace have the same SQL endpoint and they shouldn't have, right?

Is it intended to be like that and if not, how to handle this?

Thanks in advance

[burakkaragoz · Accepted solution]

Hi @Manu002 ,

This behavior is expected in Microsoft Fabric. Currently, SQL Endpoints are shared at the workspace level, not per individual Lakehouse. That means if a user has access to the SQL Endpoint, they can query all Lakehouses within that workspace.

To manage access more granularly:

• Consider separating Lakehouses into different workspaces if isolation is required.
• Use row-level security (RLS) within the Lakehouse to restrict data access.
• Only admins can manage certain permissions like ReadData, so if you're just a member, you may not see or assign all access levels.

Hopefully, Microsoft will introduce more granular SQL Endpoint controls in future updates.

[v-menakakota]

Hi @Manu002   ,

May I ask if you have resolved this issue? If so, please mark the helpful reply and accept it as the solution. This will be helpful for other community members who have similar problems to solve it faster. 

Best Regards, 
Menaka.
Community Support Team  

[burakkaragoz]

Hi @Manu002 ,

Just checking in – did the steps I shared help resolve the issue?

✅ If it’s working now, feel free to mark the response as the Accepted Solution. This helps others who face the same issue find the fix faster.

✨ And of course, a little Kudos would be much appreciated!

If you're still running into trouble, let me know what you've tried so far and I’ll help you dig deeper. We’ll get it sorted!

[v-menakakota]

Hi @Manu002 ,

May I ask if you have resolved this issue? If so, please mark the helpful reply and accept it as the solution. This will be helpful for other community members who have similar problems to solve it faster. 

Best Regards, 
Menaka.
Community Support Team 

[v-menakakota]

Hi @Manu002  , 

Thanks for reaching out to the Microsoft fabric community forum. 

I would also take a moment to thank @burakkaragoz , for actively participating in the community forum and for the solutions you’ve been sharing in the community forum. Your contributions make a real difference. 
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions. If the response has addressed your query, please accept it as a solution so that other community members can find it easily. 

Best Regards, 
Menaka.
Community Support Team  

[burakkaragoz]

Thank you both for the detailed clarification. The distinction that SQL Endpoints are scoped at the workspace level is crucial, especially for organizations aiming to implement fine-grained access control across multiple Lakehouses.

While separating Lakehouses into different workspaces is a viable workaround, it introduces operational overhead—especially in environments with many data domains or tenants. In such cases, managing workspace sprawl, permissions, and deployment pipelines can become complex.

Implementing Row-Level Security (RLS) within a shared Lakehouse is a good mitigation strategy, but it doesn’t fully address scenarios where metadata isolation or query surface minimization is required (e.g., in multi-tenant architectures).

It would be highly beneficial if Microsoft Fabric could support:

• Lakehouse-scoped SQL Endpoints, allowing tighter control over query access.
• Endpoint-level permission granularity, such as restricting visibility to specific tables or views.
• Auditing and monitoring at the SQL Endpoint level to track cross-Lakehouse access.

Looking forward to future updates that might bring more flexibility in this area. Thanks again for the insights!

[v-menakakota · Accepted solution]

Hi @Manu002 ,

Thank you for reaching out to us on the Microsoft Fabric Community Forum.

Thank you @burakkaragoz for providing possible solution. SQL Endpoints are scoped at the workspace level, not at the individual Lakehouse level. So if a user has access to the workspace SQL Endpoint, they will be able to query all Lakehouses within that workspace.
To manage access more securely, create separate workspaces and Use Row-Level Security (RLS) to control data visibility within a shared Lakehouse.

If this post was helpful, please give us Kudos and consider marking Accept as solution to assist other members in finding it more easily

[burakkaragoz · Accepted solution]

Hi @Manu002 ,

This behavior is expected in Microsoft Fabric. Currently, SQL Endpoints are shared at the workspace level, not per individual Lakehouse. That means if a user has access to the SQL Endpoint, they can query all Lakehouses within that workspace.

To manage access more granularly:

• Consider separating Lakehouses into different workspaces if isolation is required.
• Use row-level security (RLS) within the Lakehouse to restrict data access.
• Only admins can manage certain permissions like ReadData, so if you're just a member, you may not see or assign all access levels.

Hopefully, Microsoft will introduce more granular SQL Endpoint controls in future updates.