Hub Workspace with Centralised Lakehouse

[VictorMed]

Hi All,

We want to share company-wide data across multiple teams in a centralised lakehouse with schemas.

Our current approach has been:

1. New Workspace where only the admin security group has a role (admin)
2. Created 3 new security groups that are mutually exclusive (Executive, SLT, Employees)
3. Created a new Lakehouse with a schema created and named after each security group
4. Directly shared the lakehouse with each security group, with only read permissions
5. Deleted DefaultReader role
6. Created a OneLake security role for each security group with only access to their schema
7. Created a custom DB role in SQL security to grant access to their schema and deny select to the other 2 schemas
8. Revoke select to all schemas from public

With the above steps, I have test accounts in each security group, and currently, they can't access the lakehouse or SQL endpoint via portal or SSMS.

If sharing the workspace with viewer access, all accounts have access, bypassing SQL security, which defeats the purpose of the solution.

Am I missing something? 

Thanks,

Victor

[v-saisrao-msft]

HI @VictorMed,

Checking in to see if your issue has been resolved. let us know if you still need any assistance.

Thank you.

[v-saisrao-msft]

HI @VictorMed,

Have you had a chance to review the solution we shared by @lbendlin @Olufemi7? If the issue persists, feel free to reply so we can help further.

Thank you.

[Olufemi7 · Accepted solution]

Hello @VictorMed,
Looks like the issue is the difference between workspace access and SQL security.
Your schema permissions only affect the SQL endpoint, but once users get Viewer access to the workspace, they can access the Lakehouse more broadly through the Fabric portal.
Also worth checking the removal of the DefaultReader role, since that can break normal Lakehouse access.
From what I have seen, Fabric still does not fully support strict schema isolation inside a single shared Lakehouse in the same way SQL Server does.
Most people end up separating access using different Lakehouses, workspaces, or semantic models instead.

Docs:
Data security overview 
SQL granular permissions in Microsoft Fabric 

[lbendlin]

I think that 4.  only gives "read" access to semantic data, not the actual data.  You need to specifically grant readall for the data.