OneLake Security

Applying Fabric OneLake Security

Yash Vardhan Vashistha — Wed, 14 Jan 2026 21:58:06 GMT

1. Executive Summary

In this blog, I expound more on my previous blog post called ‘Overview about OneLake Security’. In this post, I will provide a detailed demonstration of applying Object Level Security (OLS), Column Level Security (CLS), and Row Level Security (RLS) in Fabric OneLake, as well as cover role testing and common errors you might run into.

Remember that OneLake security helps you to apply Role Based Access Controls (RBAC) to the data stored in OneLake. You will need to be either an Admin or a Member of the workspace to be able to create these security roles

2. Preparing the Data

Before I show you how to create the security roles, let us first start by creating a table with data in a Fabric Lakehouse.

2.1. Adding Data to a Lakehouse

I have an excel file with different sheets containing data. For this demo, I will bring in data from one of the Excel Sheets and store it in a table called ‘Fact2’. I have already created a Lakehouse called LH_01 in a workspace called ‘Practice’. I, then, proceed to save the Excel Workbook in the LH_01 which was saved under the ‘Files’ section of the Lakehouse. I navigate to LH_01 and select Get Data and create a ‘New pipeline’. Follow along with the pictures below to create a new pipeline to get data from one of the sheets in the Excel Workbook and store it in a new table called ‘Fact2’.

I select the Lakehouse I created previously called LH_01.

I select the option to load the data from the Files section of the Lakehouse and select the Excel Sheet called ‘Sheet1 2020’ to load the data into a new table.

Before loading in the data to a new table, we also have an option to correctly map the columns with the data type we expect them to store and name the new table created. For instance, I make sure that my Year, Quarter and Month columns are saved as integers, and the table is called ‘Fact2’.

After the pipeline has been created, it will kick off and after waiting for bit, should succeed in pulling in all the data in ‘Fact2’.

After the pipeline successfully runs, you will notice a new table in LH_01 called ‘Fact2’.

3. Creating Roles

You can create roles in OneLake by navigating to the Lakehouse (in our case LH_01) and clicking on the ellipsis (3 dots) on the top right of the Home ribbon and selecting ‘Manage OneLake security (preview)’ which will open a sidebar window containing a single role called DefaultReader by default. Click on ‘New’ to create a new role.

3.1. Creating Object Level Security (OLS)

OneLake security, which at the time of writing this post is still in preview, provides the ability to create object level security roles which can be used to secure specific tables or folders.

After clicking ‘New’ I get an option to define a new role the details for which you can see below. In the option to add data, I select the Fact2 table we created above.

During the role creation, you can also preview what the user will potentially see using the ‘Data preview’ tab. As you can see, the users belonging this role will only be able to access Fact2. Even though we selected only one table for demonstration, you can select up to 500 individual items. Similarly, if there are certain files you want to secure which may be housed under folders, you can choose to secure those as well.

3.1.1. Testing OLS

Now that we have created a role for OLS which gives the user the ability to read the table ‘Fact2’, I wanted to show you how you can test if the role is working. You can test the roles a couple of different ways, for example, trying to run a query on a Fabric Notebook, using Power BI report, etc. I'll demonstrate how the roles work using a Power BI report, which also lets me view the data at the same time.

In order to test the roles and visualize the data, I create a Fabric Semantic Model called ‘SM_01’ and add Fact2 to the model.

Next, I open a blank Power BI report, sign in and connect to SM_01 which shows me only 1 table indicating that the role is working.

Below is another image where you can see that I am to read all the data from Fact2 in Power BI.

3.2. Creating Column Level Security (CLS)

CLS allows you to define access to specific columns in a table stored in OneLake instead of providing full access to a table like we saw above. Microsoft, in their official documentation, does highlight an important point where they underscore the importance of using ‘Fabric Engines’ (for example, Lakehouse, Power BI engine, Spark engine, etc.) for the CLS to work. Using CLS with ‘non-Fabric engines’ (for example, third party engines like Hadoop clusters, or custom Python or R scripts) will result in the entire table blocked from being read. Furthermore, CLS rules will be enforced only for users with the ‘Viewer’ role in the workspace.

Next, let us create a CLS role in a similar fashion like OLS where we select ‘New’ and create a new role, in my case I named it CLSFact2 as I want to restrict a few columns from Fact2 table we created earlier.

After creating the above role, click on the role details (ellipsis or 3 dots) next to the role we just created and select ‘Column Security’. I decided to restrict two columns from ‘Fact2’.

3.2.1. Note on SQL Analytics Endpoint

Microsoft mentions in their documentation a few extra steps the user will need to take to make sure that users querying data via SQL only see the data they are authorized to access, maintaining compliance and protecting sensitive information. It integrates OneLake’s role-based access controls with the SQL interface, so permissions defined in OneLake apply consistently across all query methods.

When you enable this setting, SQL queries executed through the analytics endpoint will respect OneLake’s security rules (RLS, CLS, etc.).

Here is where you can find clear steps on how to enable OneLake security with SQL analytics endpoint - Column-level security - Microsoft Fabric | Microsoft Learn

3.2.2. Testing CLS

In order to test the CLS we created above which restricts the user from querying two specific columns – Offering and S-Ind, similar to OLS, I add the test user called ‘Fabric User’ to the role.

Next, I navigate to my Power BI report and hit ‘Refresh’ on the Home ribbon to make sure that the changes I made to the role reflect in the report. Upon refreshing, I notice that I cannot read the two columns we removed from the role – Offering and S-Ind, see the image below.

3.3. Creating Row Level Security (RLS)

Till now we have covered OLS and CLS which can secure files, tables or columns in your dataset. However, if we wish to restrict only certain rows of data, for example, only allowing employees working in North America to see data for their geography and not for the entire globe, we will need to implement RLS which is a feature of OneLake security that allows defining row level restrictions for ‘tabular’ data where each row corresponds to a single record (e.g., a transaction or an entry), and each column represents a specific attribute or field (e.g., date, amount, region).

Similar to CLS, Microsoft differentiates between Fabric and non-Fabric engines where RLS applies to only ‘Fabric engines’ and will block the entire table for ‘non-Fabric engines’. Similarly, RLS rules will be enforced only for users with the ‘Viewer’ role in the workspace.

Below I create a new role called ‘RLSFact2’ and select Fact2 table as I need to add RLS to that table.

RLS uses SQL syntax to define the security that needs to be applied. It takes the form of a ‘SELECT’ statement with RLS rules defined in the ‘WHERE’ clause of the statement. Since, defining incorrect or unsupported SQL will result in the entire table being restricted, it is a good idea to take a look at the correct way of defining the rules.

SELECT \ FROM {schema_name}.{table_name} WHERE {column_level_boolean_1}{column_level_boolean_2}...{column_level_boolean_N}*

In our example, I define a simple rule –

SELECT \ FROM dbo.Fact2 WHERE Month = 7*

The above rule will restrict the user to only query data for July, i.e. where month number equals 7.

It is a good idea to go through all the syntax rules once before creating your first role here - Row-level security - Microsoft Fabric | Microsoft Learn

3.3.1. Testing RLS

Next, we test the role we created above. The first thing we must do is add our test user to the RLSFact2 role.

Next, I refresh my Power BI report again to ensure that the changes we made reflect in Power BI. After refreshing I can see the columns that were removed from the CLSFact2 and can now only read data where Month=7. Look at the image below.

3.4. Combining RLS and CLS

There will be scenarios where you might want to apply both CLS and RLS together to ensure that sensitive columns and out-of-access rows can be restricted for users. Using our test data, I can create a security role to combine both CLS and RLS together where I can restrict two columns – say, ‘Offering’ and ‘S-Ind’ using CLS and also restrict the users from accessing data for Q4 using RLS. I can achieve this by creating a ‘SINGLE’ role that incorporates both these rules together. Note the emphasis on ‘single’ as Microsoft mentions that if you want to restrict access using both CLS and RLS, you shall only use a single role to define both CLS and RLS. This is because “OneLake security doesn't support the combination of two or more roles where one contains RLS rules and another contains CLS rules.”

Below I create a single role called ‘CLSRLSFact’ to secure Fact table that I originally created. After I create the role, I click on more details and start defining CLS and RLS for that role. For CLS, I will remove access to ‘Offering’ and ‘S-Ind’ and for RLS, I will restrict the user from access Q4 data by applying a filter on ‘Quarter’ column.

3.4.1. Testing CLS and RLS

Finally, we test how RLS and CLS work together. However, before I test the CLSRLSFact role, which contains both CLS and RLS in a single role, I wanted to highlight how querying data from the table will fail if you create ‘SEPARATE’ roles for CLS and RLS. Since, we have separate roles created for CLS and RLS and have our test user included in both, when I try to visualize data by creating a simple table in Power BI, I receive an error indicating that a combination of CLS and RLS is not supported. I wanted to showcase this special case in case you run into this error and are scratching your head thinking why the roles are not working.

To correct this error, I remove the test user from both CLS and RLS roles and add them to the new CLSRLSFact role.

After I hit refresh on my Power BI report, and test CLS and RLS together, I can now see the table working. Moreover, I can not see the two columns we omitted – Offering and S-Ind and I also cannot see the data for Quarter 4 indicating that our combination of RLS and CLS is working as expected when defined in a single role.

Overview about OneLake Security

Yash Vardhan Vashistha — Tue, 06 Jan 2026 16:53:47 GMT

1. Executive Summary

OneLake Security, is a critical component of Microsoft Fabric that enables granular, role-based access control (RBAC) to data stored within OneLake. It allows organizations to define precise permissions for users and groups, ensuring data confidentiality and integrity across various compute engines. This post outlines the key features of OneLake security, including its hierarchical model, different permission types (Workspace, Item, Compute, and OneLake specific), and detailed explanations of Column-Level Security (CLS), Row-Level Security (RLS), and Table/Folder-Level Security (OLS). It also covers inheritance, traversal, shortcut security, authentication, and current limitations.

2. Core Concepts of OneLake Security

OneLake is designed as a hierarchical data lake, similar to ADLS Gen2 or a standard file system. Security can be applied at various levels within this hierarchy, with specific treatment for levels correlating with Fabric concepts.

2.1. Hierarchical Security Model

The security structure within OneLake can be visualized as:

Workspace: "a collaborative environment for creating and managing items."
Item: "a set of capabilities bundled together into a single component. A data item is a subtype of item that allows data to be stored within it using OneLake."
Folders: "folders within an item that are used for storing and managing data."

OneLake security inherently controls all access to OneLake data, with permissions potentially inherited from parent items or workspace permissions.

2.2. Permission Types in OneLake

2.2.1. Workspace Permissions

Workspace permissions provide "coarse-grain" access control to all items within a workspace. There are four roles:

Admin: Full control, can add other Admins and Members, write data, create items, and read data.
Member: Can add Members, write data, create items, and read data.
Contributor: Can write data, create items, and read data.
Viewer: Can only read data. By default, Viewers cannot see files in OneLake unless OneLake security is used to grant access.

Important Note: "Since Workspace Admin, Member and Contributor roles automatically grant Write permissions to OneLake, they override any OneLake security Read permissions." OneLake security RBAC Read permissions only apply to the Viewer role.

2.2.2. Item Permissions

Item permissions are granted directly to a user via the sharing feature or an item's "Manage permissions" page, without making them a workspace member. They control access to the specific item and its endpoints. Key item permissions include:

Read: See item metadata, but no data in SQL or OneLake.
ReadData: See data in SQL, but not in OneLake.
ReadAll: See data in OneLake (with caveats for OneLake security enabled items).

2.2.3. Compute Permissions

Access can also be granted through the SQL compute engine. This "only applies to users accessing data through SQL, but you can use this security to give more selective access to certain users." SQL supports restricting access to specific tables and schemas, as well as row and column level security.

Crucial Point on Mismatch: "Users might see different results when they access data through SQL compared to when they access data directly in OneLake, depending on the compute permissions applied. To prevent this mismatch, ensure that a user's item permissions are configured to only grant them access to either the SQL analytics endpoint (using ReadData) or OneLake (using ReadAll or data access roles (preview))."

2.2.4. OneLake Security (Preview)

OneLake security "allows users to define granular role-based security to data stored in OneLake, and enforce that security consistently across all compute engines in Fabric." It's an evolution of the "OneLake data access roles (preview)" feature. Key components of a OneLake security role include:

Data: Tables or folders accessible.
Permission: Actions allowed on the data.
Members: Users assigned to the role.
Constraints: Specific rows or columns excluded from access (e.g., RLS, CLS).

"Users that aren't part of a role can't see any data in that lakehouse."

3. Granular Data Access Control Features

OneLake Security offers sophisticated controls for defining precise data access.

3.1. Column-Level Security (CLS)

CLS allows users to "have access to selected columns in a table instead of full access to the table." Any columns removed from a user's allowed list are not visible.

3.1.1. Enforcement:

Filtered tables in Fabric engines: Users only see allowed columns in Spark notebooks, SQL analytics endpoint, and Semantic models.
Blocked access to tables: Tables with CLS rules cannot be read outside supported Fabric engines.
Scope: CLS rules are only enforced for Delta parquet tables. For non-Delta tables, CLS rules block access to the entire table.

3.1.2. Definition:

Defined as part of a OneLake security role for Delta-parquet tables in the Tables section of an artifact.
By default, CLS is disabled, granting access to all columns. Users enable CLS and "remove columns from the list to revoke access."
Important: "Removing access to a column doesn't deny access to that column if another role grants access to it."

3.2. Row-Level Security (RLS)

RLS "allows for defining row-level data restrictions for tabular data stored in OneLake." It enables defining roles with rules for filtering data rows.

3.2.1. Enforcement:

Filtered tables in Fabric engines: Users only see allowed rows in supported Fabric engines (e.g., Spark notebooks).
Blocked access to tables: Tables with RLS rules cannot be read outside supported Fabric engines.
Scope: RLS rules are only enforced for Delta parquet tables. For non-Delta tables, RLS rules block access to the entire table.

3.2.2. Definition:

RLS rules use SQL syntax within a WHERE clause of a SELECT statement to specify which rows a user can see.
Example: SELECT * FROM Sales WHERE Amount>'50000' AND State='CA'
Maximum RLS rule length: 1000 characters.
Supported operators include =, <>, >, >=, <, <=, IN, NOT, AND, OR, TRUE, FALSE, BLANK, NULL.

3.3. Table and Folder Security (Object-Level Security - OLS)

OLS "allows for granting access to specific tables or folders in a data item." This enables permissions for both structured and unstructured data at the folder level.

Security can be configured on Delta-parquet tables (which are represented as folders) and schemas.
Users select specific tables or folders to include in a OneLake security role. "You can select up to 500 items per role."

3.4. Combining RLS and CLS

RLS and CLS can be used together to restrict user access to a table, but they must be applied using a single OneLake security role.

"OneLake security doesn't support the combination of two or more roles where one contains RLS rules and another contains CLS rules." Users attempting this "receive query errors."
Single Role: RLS and CLS rules compose as filters on the full schema and data. For example, if a user has access to Table1 with Column1 removed (CLS) and Column2 = "US" (RLS), they will see all columns except Column1 and only rows where Column2 is "US".
Multiple Roles: For RLS and CLS across multiple roles, "the security combines through a union of each category." This means if one role grants full column access, and another restricts a column, the user gets full access. Similarly, RLS rules combine with an OR between SQL statements, so full table access in one role results in all rows being visible.
Important: "If two roles combine such that the columns and rows aren't aligned across the queries, access is blocked to ensure that no data is leaked to the end user."

4. Inheritance, Traversal, and Shortcuts

4.1. Inheritance in OneLake Security

"For any given folder, OneLake security permissions always inherit to the entire hierarchy of the folder's files and subfolders." If Role1 grants read permission to folder1, it automatically applies to all files and subfolders within folder1.

4.2. Traversal and Listing in OneLake Security

OneLake security "provides automatic traversal of parent items to ensure that data is easy to discover." Granting read permissions to a subfolder (e.g., subfolder11) implicitly grants the ability to list and traverse its parent directory (folder1). This traversal does not extend to other unrelated items, keeping them secure.

4.3. Shortcut Security

Shortcuts simplify data management in OneLake.

Internal Shortcuts (within OneLake): Permissions always inherit to internal shortcuts where the target folder is defined. Access to data through an internal shortcut is authorized by the calling user's identity against the target path's permissions.
Caveat for Power BI semantic models or T-SQL: "the calling user's identity isn't passed through to the shortcut target. The calling item owner's identity is passed instead, delegating access to the calling user."
Defining OneLake security permissions directly on an internal shortcut is not allowed; they must be defined on the target folder in the target item (currently only Lakehouse supports this).
External Shortcuts (ADLS, S3, Dataverse): OneLake supports defining permissions for these shortcuts. These permissions are applied on top of the delegated authorization model. Both the external connection's authorization (e.g., S3 connection for user1) and OneLake security's authorization (for requesting user2) must grant access for user2 to see the data.
Permissions set on a folder within an external shortcut recursively inherit to all subfolders.

5. Authentication, Audit, Encryption, and Networking

5.1. Authentication

OneLake uses Microsoft Entra ID for authentication, supporting user identities and service principals. OneLake automatically extracts the user identity from tools using Microsoft Entra authentication and maps it to Fabric portal permissions.

5.2. Audit Logs

OneLake audit logs track user activities, with operation names corresponding to ADLS APIs (e.g., CreateFile, DeleteFile). However, "OneLake audit logs don't include read requests or requests made to OneLake via Fabric workloads."

5.3. Encryption and Networking

Data at Rest: Data in OneLake is "encrypted at rest by default using Microsoft-managed keys." This is transparent, rotated appropriately, and FIPS 140-2 compliant. Customer-managed keys are not currently supported.
Data in Transit: Data moving across the public internet between Microsoft services is "always encrypted with at least TLS 1.2" (preferring TLS 1.3). Traffic between Microsoft services routes over the Microsoft global network. Inbound OneLake communication also enforces TLS 1.2+. Outbound Fabric communication to customer-owned infrastructure prefers secure protocols but may fall back to older, insecure ones.
Private Links: Supported for configuring private links in Fabric.

5.4. External Application Access

Admins can enable or restrict access to OneLake data from applications outside the Fabric environment through a tenant setting. When enabled, users can access data from sources like custom ADLS APIs or OneLake file explorer. When disabled, users can still access data from internal Fabric apps (Spark, Data Engineering, Data Warehouse) but not external applications.