Forum Discussion
Fabric - Governance
Hi everyone,
I’m currently working on a data architecture scenario in Microsoft Fabric and would appreciate your insights.
We are ingesting data from an existing DWH where access is strictly governed using Row-Level Security (RLS) and Column-Level Security (CLS) based on user profiles. The goal is to bring this data into Fabric and make it available for citizen developers.
In Fabric, we understand that RLS and CLS can be applied on SQL endpoints. However, the challenge is that users also have access to other components such as notebooks, lakehouse tables, and other experiences. This creates a potential gap, as users could bypass the SQL endpoint and access the underlying data directly, effectively bypassing the security rules that were enforced in the source DWH.
Our main concern is:
How can we enforce RLS and CLS consistently at the data level in Fabric, regardless of the access path (SQL endpoint, notebook, etc.)?
We are aware that OneLake security currently does not fully enforce access based on the caller’s identity in a way that aligns with traditional DWH security models.
Has anyone implemented a robust pattern or architecture to ensure data-level security (RLS/CLS) is respected across all Fabric workloads?
Are there recommended best practices, design patterns, or workarounds to prevent bypass scenarios?
Thanks in advance for your help!
Hi ,
Fabric does offer item-level permissions directly on lakehouses. You can assign Read, ReadAll, ReadData, and Write without granting workspace-level access. That is an important distinction from workspace roles.The key permission to understand is ReadData. It scopes access to the SQL analytics endpoint only. Users with ReadData but not ReadAll are confined to that endpoint, which means your RLS and CLS rules apply and direct Delta file access through notebooks or OneLake is blocked.
The bypass risk you are describing is specific to users or service principals who hold ReadAll or higher. ReadAll grants direct access to the underlying Delta files, which sits outside the SQL endpoint layer where RLS and CLS are enforced. At that point, your row and column policies do not apply.
So the practical governance pattern is
- Grant citizen developers ReadData on the lakehouse, not ReadAll.
- Apply RLS and CLS at the SQL analytics endpoint as your enforcement layer.
- Audit and restrict ReadAll grants to pipeline service principals and data engineers only.
- Use Power BI semantic models or the SQL endpoint as the approved query surface for governed data.
OneLake shortcut chaining is still worth watching. RLS does not propagate through shortcuts, so any shortcut pointing at a governed lakehouse needs the same permission discipline applied at the source.
The security model is workable. The risk comes from ReadAll being granted more broadly than necessary.
Thank you!
Proud to be a Super User!
📩 Need more help?
✔️ Don’t forget to Accept as Solution if this guidance worked for you.
💛 Your Like motivates me to keep helping
3 Replies
MJParikhSuper User
Hi ,
Fabric does offer item-level permissions directly on lakehouses. You can assign Read, ReadAll, ReadData, and Write without granting workspace-level access. That is an important distinction from workspace roles.The key permission to understand is ReadData. It scopes access to the SQL analytics endpoint only. Users with ReadData but not ReadAll are confined to that endpoint, which means your RLS and CLS rules apply and direct Delta file access through notebooks or OneLake is blocked.
The bypass risk you are describing is specific to users or service principals who hold ReadAll or higher. ReadAll grants direct access to the underlying Delta files, which sits outside the SQL endpoint layer where RLS and CLS are enforced. At that point, your row and column policies do not apply.
So the practical governance pattern is
- Grant citizen developers ReadData on the lakehouse, not ReadAll.
- Apply RLS and CLS at the SQL analytics endpoint as your enforcement layer.
- Audit and restrict ReadAll grants to pipeline service principals and data engineers only.
- Use Power BI semantic models or the SQL endpoint as the approved query surface for governed data.
OneLake shortcut chaining is still worth watching. RLS does not propagate through shortcuts, so any shortcut pointing at a governed lakehouse needs the same permission discipline applied at the source.
The security model is workable. The risk comes from ReadAll being granted more broadly than necessary.
Thank you!
Proud to be a Super User!
📩 Need more help?
✔️ Don’t forget to Accept as Solution if this guidance worked for you.
💛 Your Like motivates me to keep helping
v-aatheequeCommunity Support
Hi hbentaleb
Have you had a chance to look through the responses shared earlier? If anything is still unclear, we'll be happy to provide additional support.- v-aatheeque
Hi hbentaleb
Following up to confirm if the earlier responses addressed your query. If not, please share your questions and we’ll assist further.