Recently, Microsoft came out with a private preview for OneLake Security in Microsoft Fabric lakehouses. This is amazing, it is a feature I have been waiting for now for a long time. The promise with Fabric would be that security in the most detailed grain (both row-level and column-level) would be implemented in OneLake. However, developing this apparently was difficult, so only now (July 2025) we’re getting the private preview of OneLake Security (previously called OneSecurity).
An Overview of Security in Microsoft Fabric
Before we dive in, let’s create an overview of the security options we have today in Fabric. I will NOT touch every single item, but let’s look at the most widely used options instead.
If you want to dive right into OneLake Security, you can skip the next few paragraphs by clicking here.
User Access to Workspaces and Apps
Maybe the first level of security, is that of getting users to actually log in to Fabric and Power BI. Assuming they have the appropriate license (in case of Power BI) they should be able to login to app.powerbi.com or app.fabric.microsoft.com. Then, within the Power BI/Fabric portal, they should have access to “My Workspace. If you want to collaborate, you have to assign users to group workspaces.
Best practice is to create security groups in Microsoft Entra ID, and then assign those groups to the workspaces. But you could also assign individual users to the workspaces. The process is quite simple.
In your workspace, you go to Manage Access, and you click the large green button saying “Add people or groups”. From there, you can search for a user’s or group’s email ID and add them to one of four roles (Viewer, Contributor, Member, Admin). Viewer only gives read access to objects in the workspace, as Contributor you can create and alter most other objects. Then, as a Member, you are allowed to add users with lower permissions than Member (i.e. Viewer or Contributor), and as an Admin you can do everything including adding or removing access to the workspace and even deleting the workspace altogether.
Congratulations, you now have access to the workspace. However, we are not there yet regarding the actual access to objects and their data.
User Access to Power BI content
For Power BI, we should be publishing Apps. An App lets you group content together and distribute it across your user base in a read-only format. For the end-user, this is preferable over direct report access in the workspace because it allows them to interact with the reports without all the fluff around editing reports.
You can assign reports in your workspace to be included in the app. A workspace can only have one app, however, you can assign reports to one or more audiences. An audience can then be shared with individual users or, preferably, Entra ID groups.
This is user access to Power BI content for consumers, comparable to how we would assign developers to workspaces. It allows you to secure who can see which reports, but not who can see which data inside those reports.
Power BI RLS or Row-Level-Security
Within Power BI semantic models we have the option of creating roles for row-level-security or RLS. This is an awesome feature that has been around for years, and I use very often to control what data users get to see. As a consultant, I see a lot of different companies. Some open up their books to every user, and some are really restrictive in what they show their users.
If you want to show the same report to lots of users, and have the users only look at their own data, you can do so with RLS.
Inside RLS roles you can define what data a role member gets to see, by applying DAX filters to tables. You can even create dynamic RLS where you use DAX to lookup the user’s email ID and use that to dynamically filter the model.
RLS for Lakehouses
For a long time, RLS or row-level-security has not been available to lakehouses in Microsoft Fabric. And that’s a shame, because it forces us to design architectures in which we duplicate RLS setups to the semantic models. That’s not a problem in smaller environments with maybe one single semantic model containing the entire gold layer of the data lake, but for larger organisations with many semantic models that poses an issue.
OneLake Security in Lakehouses for Microsoft Fabric
Luckily, we are now seeing that OneLake Security is finally coming to us. Currently, as of writing this article in July 2025, the feature is still in private preview. That means you have to ask Microsoft for access. It also means things can be broken, and it can even mean that the feature will never make it to GA status (general availability).
However, given the importance of fine grain control over data access inside lakehouses I definitely think Microsoft are pushing this feature to GA. We simply don’t know when, but I’m convinced it will come at some point.
The OneLake Security preview allows us to implement security on lakehouses in the following ways:
- All data or a subset of the data
- All Files, or a folder of files, or a single file
- All tables, or a single schema of tables, or a single table
- Columns in a table
- Rows in a table
In the paragraphs below I will go through this setup step by step, showing how the preview features work and how that looks like from the user’s perspective (proving the security works).
Before you start, you will need at least a Lakehouse object in your Fabric workspace that is Schema Enabled. Schemas in lakehouses are still in (public) preview, so beware, but in my testing it seems that they are quite stable these days. From here on, I will assume you have already setup the schema enabled lakehouse and a PySpark notebook connected to this lakehouse.
I have created a new schema “masterdata” next to the default schema “dbo” and loaded three two-column tables into the lakehouse: dbo.Companies, dbo.Users, and masterdata.Products.
With that setup, we are now able to demonstrate the following OneLake Security features.
Securing Schemas in Microsoft Fabric Lakehouses
First of all, head over to the “Manage OneLake data access (preview)” button on top of the menu in your lakehouse.
First of all: be sure to delete the Default role that was created. Everyone with read access to the lakehouse has access to that role, and any restrictive role you create will not have impact.
After that, create a new role and call it something descriptive that works for you. I called it “SecurityDemo”, because, well, it is a demo of the security 🙂
Now when I log in to the workspace using my other account, I see the following data in the lakehouse:
Querying the dbo schema (that this account has access to) works perfectly fine as you can see.
But when I try and query the masterdata.Products table I get an error, as it should be:
Securing Individual Tables with OneLake Security
The same logic applies to working with individual tables in a lakehouse. If I were to secure my second account to only use the dbo.Users table, this would happen:
And then from the user account I would see this:
Column Level Security in OneLake Security
Now we get into the more granular parts of OneLake Security with permissions on column and row level. Let’s start with the column level.
I will assume the user has access to the dbo.Users table. This table consists of two columns: id and name.
Now we want to only disclose the id column to this user. Maybe because the name is confidential, or whatever reason. Let’s go into our security role and click on edit:
Navigate to the table you want to secure and click the three dots:
Then select Column security (preview). It will tell you there are no CLS rules yet, you have to create them:
That is easy, just click Enable CLS and continue to the next page:
Now the specified column is gone from the view users in this role get. Mind you: if the user has the “Viewer” role on the workspace, they can only browse table data from the lakehouse using the SQL Analytics Endpoints.
Anytime you try to work with the data secured by CLS from, for example, a notebook, you get errors. You can mitigate this by granting the user “Execute” rights to the notebook. If you do that, and then execute a “select *” statement against the table, you will get a result with only the columns you are allowed to see:
Alternatively, when you go to the SQL Analytics Endpoint, you can browse the tables you might have access to. From the screenshot below it seems that the engine understands your access currently is limited to the dbo.Users table:
This is behaviour as expected. However, when I open the dbo.Users table in the object explorer, I do see the “name” column that I previously removed from this user’s role. They should not be able to see it:
However, when I try to query the column I get an error message stating that I do not have permissions to read data from this particular column. That is strange, as this worked perfectly fine from the Spark notebook when executing a SparkSQL query.
Note: this was documenten in the known limitations in the official Microsoft OneLake Security CLS documentation.
Selecting only the ‘id’ column here is fine, and yields a result.
Row Level Security in OneLake Security
The counterpart to CLS is RLS or row-level security. This feature is widely known and used in Power BI to allow access to a single semantic model where each user sees their own data.
OneLake Security also includes RLS which helps us to define subsets of rows that users are allowed to query within a Microsoft Fabric lakehouse.
We can create RLS rules by going to the same menu as for CLS. Go to the lakehouse, click on “Manage OneLake Security (preview)”, and edit the role (a role must already exist in order to manage RLS and CLS).
From there, I will now edit my existing role and remove all previous access controls. Members of this role are now allowed to see all tables. This is the result:
Now we can click on one of the tables, let’s do masterdata.Products for now, to create row-level security in OneLake Security.
From there, we can write a SQL query to determine which records a user in this role gets to see.
And indeed, looking at the query in the SQL Analytics Endpoint we now only get rows for which the id is smaller than or equal to 2.
Conclusion
It is nice to finally be able to implement fine-grain security rules to our Microsoft Fabric lakehouses using OneLake Security. Overall, the interface feels a bit clunky and at times unresponsive. I’m sure that will be fixed though, and we will have a way to properly secure access to our tables in a more granular way.
One use case we already have for this is hosting multi-tenant dataplatforms. For a software company we created a solution to prepare, store and analyse data for their many customers, however, in the Gold layer we had to create a lakehouse per customer. That will not be necessary anymore once proper RLS will be set in place.
What other use cases will you have once we get General Availability for OneLake Security?