Security! It’s undoubtedly one of the key considerations when implementing a data platform within the organization. Apparently, there are multiple layers and “flavors” of security – network security, data storage security, data access, and data protection, to name a few. In this article, we will focus on understanding different concepts and features to control data access in Microsoft Fabric.
If you are not sure what Microsoft Fabric is, I suggest you start by reading this article.
This article may help you understand topics relevant for DP-600 (Fabric Analytics Engineer) and DP-700 (Fabric Data Engineer) exams
Understanding Fabric Storage Architecture
The cornerstone of the entire Microsoft Fabric platform is OneLake. OneLake is a central storage repository for the entire organization, regardless of whether the organization chooses to use a lakehouse, warehouse, KQL database, or any other Fabric item for storing the data. In the end, all roads lead to OneLake:)
In simple words, OneLake is nothing else but a logical structure of files and folders, as depicted in the following illustration:

As you may see, the OneLake itself is at the top level of this hierarchy. Then, we have one or multiple workspaces that serve as containers for various Fabric items, such as lakehouses, warehouses, KQL databases, semantic models, and so on. When you go one level further and open, let’s say, a lakehouse, there are a bunch of folders inside, each representing an individual table. Finally, each table folder consists of one or more files.
Let’s now examine the conceptual structure of OneLake:

Understanding the conceptual structure of OneLake will help us break down how this structure impacts the data access control options in Fabric. Hence, let’s start from the top…
Workspace-level Access Control
When you grant access to a workspace, a user or a group of users get access to all the items in the particular workspace! Imagine the scenario where you have a workspace that contains five lakehouses, two warehouses, and 10 semantic models…The workspace role will enable the user to access all of these items. Of course, depending on the role itself, the user can perform a certain set of actions on top of the items, but the key thing to keep in mind here is: with workspace roles, every single item in the workspace is accessible.
There are four workspace roles:
- Admin
- Member
- Contributor
- Viewer
The following table from Microsoft Learn docs, shows the capability of each workspace role:

Item-level Access Control
If you need to enable a specific user or group of users to access a particular item (or maybe a subset of items) in the workspace, but not necessarily all the items in that workspace, you should grant them access by sharing this item. With this approach, the user has restricted access to a workspace (they don’t even need any of the workspace roles) and can only access the shared item.
Depending on the item type (lakehouse vs. warehouse vs. KQL database), the set of permissions might differ. Whenever you share the item with the user, it will automatically grant them the READ permission for that item.
The following illustration shows Item-level access control options for the lakehouse item:

You can find more details on the official Microsoft docs here.
When you share an item, if none of the additional permissions are checked, the user will be able to access the lakehouse from the OneLake hub, but they won’t be able to access any of the tables. This approach might be useful for Object-level and Column-level security, which we will examine in the following sections.
Row-level Security
Just to make this clear at the very beginning: here, we are not talking about the Row-level security (RLS) for Power BI semantic models. If you want to learn more about RLS for Power BI semantic models, I suggest you read this article.
Here, we are examining the RLS feature for Fabric Warehouse (and the SQL analytics endpoint of the Lakehouse). As its name suggests, it allows you to control the access to particular rows in the delta table. Here is the scenario: your company is running a business in multiple regions (USA, Europe, Asia), and you have analytics teams in each of these regions. The requirement is to restrict access so that US analysts can only see US sales data, analysts from Europe see only European sales data, and so on.
To be able to implement RLS, you either need to be an Admin, Member, or Contributor in the workspace where the item resides, OR to have elevated permissions on the warehouse/SQL analytics endpoint.
The first step is to define roles and predicates – roles determine WHO can access the data, whereas predicates define WHICH data can be accessed.
-- Creating schema for Security CREATE SCHEMA Rls; GO -- Creating a function for the analyst evaluation CREATE FUNCTION Rls.tvf_location(@analyst AS varchar(50)) RETURNS TABLE WITH SCHEMABINDING AS RETURN SELECT 1 AS tvf_location_result WHERE @analyst = USER_NAME(); GO -- Using the function to create a Security Policy CREATE SECURITY POLICY LocationRls ADD FILTER PREDICATE Rls.tvf_location(analyst) ON MySchema.MyTable WITH (STATE = ON); GO
Object-level and Column-level Security
Again, Object-level security (OLS) for Power BI semantic models is not covered in this article. If you want to learn all the details about implementing the OLS for Power BI models, I have you covered in this article. This is about OLS in the Fabric Warehouse/SQL analytics endpoint of the Lakehouse.
With Object-level security, we can control access to specific database objects – tables, views, or stored procedures. This way, we ensure that a user (or group of users) can only access those objects where they have been granted permission. For those of you coming from the SQL Server world, this might sound familiar (because it is:)) By using GRANT, DENY, and REVOKE commands, we can implement OLS in the Fabric warehouse as well.
Column-level security (CLS) works in a similar manner, but it allows for more granular access control, since you can grant access to specific columns only:

Word of warning 1: As Koen Verbeeck explains in this article, there is a possibility of circumventing Fabric warehouse security rules. If the user has been granted ReadAll permission when sharing the warehouse, they will be able to see all data in a specific table. Hence, make sure to double-check if various data access rules are in collision and always implement them by sticking with the principle of least privilege.
Word of warning 2: Please be aware that when you implement RLS/OLS/CLS in the warehouse/SQL analytics endpoint of the lakehouse, and you use Direct Lake semantic models for Power BI, all queries will, by default, fall back to DirectQuery mode. If you want to learn more about Direct Lake mode for Power BI semantic models, please refer to this article.
Folder-level Access Control
Let’s wrap it up by understanding how to control the access on the lowest level of the OneLake hierarchy – individual folders. This is implemented through one of the newer Fabric features: OneLake Data Access Roles.
The entire process of configuring the access is fairly straightforward. First, we need to create the role. Then, we choose which folders or individual files should be accessible to this role. Finally, we assign role to a user or group of users.

However, there are a few important considerations when implementing OneLake data access roles:
- These roles apply only to users accessing OneLake directly. Since it currently supports lakehouse item exclusively, keep in mind that other Fabric items, such as warehouse/SQL analytics endpoint, or semantic models, have their own security models
- When you start configuring the OneLake data access role, before you create any new role, please be aware that there is already a DefaultReader role defined for the selected lakehouse. By default, this role grants access to all folders in the lakehouse:

Hence, make sure that you don’t have the same user/group of users assigned to the DefaultReader and any custom role, because these users will then be able to see all the lakehouse folders.
- You can leverage the current set of lakehouse permissions when assigning users to a group. It’s enough to choose the option “Add users based on Lakehouse permissions”, and we can immediately add users who already have particular permission on the lakehouse:

Let’s wrap it up by examining the workflow of the permission evaluation when accessing the data in OneLake:

Please keep in mind that since workspace roles have higher precedence, if the user is a workspace Admin, Member, or Contributor (roles that automatically grant Write permissions to OneLake), this will override any RBAC (role-based-access-control) read permissions.
What about Shortcuts?
Shortcuts are one of the coolest features in the entire Fabric realm! If you’re not sure what shortcuts are, I suggest you start by reading this article. Here, I want to examine how data access control can be implemented in the context of shortcuts.
However, let’s take one step back and draw the line between the target path and the shortcut path:

For any folder in the lakehouse, RBAC permissions defined via OneLake data access roles will apply to all internal shortcuts where this folder is defined as a target path. When the user is accessing data via a shortcut to another OneLake location (think of another lakehouse, for example), the user identity will be used to authorize access to the data in the target path – which means that the user must have OneLake data access permission defined in the target path.
The following table illustrates the requirements for accessing shortcuts:

Bear in mind that the most restrictive permission applies to a particular user. Hence, if the user has Read/Write permission on the lakehouse, but only Read permission on the target path, they can’t write data to the target path.
Since OneLake data access roles are currently supported for lakehouse item only, when accessing shortcuts via semantic models or SQL analytics endpoint, the item owner identity (owner of the semantic model) delegates access to the particular user who is accessing the data.
Conclusion
Security in Microsoft Fabric is designed to support numerous scenarios by ensuring data is protected, accessible only to authorized users, and compliant with regulations. In this article, we examined various options for handling data access control and permissions, starting from workspace-level access, then explaining item-level access control, all the way to fine-grained control by implementing Row-level, Object-level, and Column-level security, as well as OneLake data access roles that support RBAC model.
Thanks for reading!
Last Updated on January 22, 2025 by Nikola