Security is one of the most critical components of enterprise analytics. With the introduction of OneLake Security in Microsoft Fabric, organizations can now centralize data security directly within the lakehouse.
This article walks through:
- What OneLake Security is
- How to enable it
- How to configure Object-Level Security (OLS)
- How to configure Row-Level Security (RLS)
- How to configure Column-Level Security (CLS)
- How security propagates to semantic models and reports
- Best practices for enterprise governance
If you want structured, hands-on guidance with Power BI and Fabric, you can explore professional training
Why OneLake Security Matters
Before OneLake Security, implementing row-level security inside a lakehouse required T-SQL, user-defined functions, or workarounds using semantic models.
You could configure traditional RLS inside Power BI semantic models using DAX. However, that meant security was defined at the model level rather than at the data source.
This created several challenges:
- Security had to be duplicated across multiple models
- Enforcement could vary across tools
- Maintenance became complex
- Risk of misconfiguration increased
OneLake Security changes this by centralizing security at the lakehouse level.
Instead of securing each semantic model individually, you secure the data once and let enforcement flow downstream.
What Is OneLake Security in a Fabric Lakehouse?
Inside a Fabric Lakehouse, you will see the option labeled “Manage OneLake Security.”
Once enabled, you can configure:
- Object-Level Security
- Row-Level Security
- Column-Level Security
All within a unified interface.
Important note: When you enable OneLake Security, it cannot be turned off. It changes how security is managed in the lakehouse.
Enabling OneLake Security
To enable OneLake Security:
- Navigate to your Lakehouse in Microsoft Fabric.
- Select Manage OneLake Security.
- Confirm the preview notification.
- The new security interface becomes available.
After activation, a default role is automatically created.
Understanding the Default Role
- Users assigned to the default role see all data.
- Users not assigned to any role see no data.
This mirrors traditional role-based security behavior in Power BI.
Creating Object-Level Security (OLS)
Assume your lakehouse contains:
- Five dimension tables
- One fact table
You want to create a role that allows access to all tables except the Customer table.
Step 1: Create a New Role
- Open Roles.
- Click Create New Role.
- Name the role “No Customer Role.”
Step 2: Set Access Type
Choose:
- Read
- Read and Write
In most reporting scenarios, Read is appropriate.
Step 3: Select Specific Objects
Instead of granting access to the entire lakehouse:
- Choose Browse.
- Select all tables except the Customer table.
- Save the role.
You have now implemented Object-Level Security. The Customer table will not exist for users assigned to this role.
Adding Row-Level Security (RLS)
Now suppose you want to restrict data to only two territories:
- Southeast
- Southwest
Assume the City dimension includes a SalesTerritory column.
Step 1: Configure Row Security
- Open the role.
- Navigate to Row Security.
- Select the City table.
Step 2: Add a SQL Filter
Use a SQL-style filter expression such as:
SELECT *
FROM City
WHERE SalesTerritory IN ('Southeast', 'Southwest')
Save the rule.
Because the fact table is related to the City dimension, filtering flows through automatically.
Users assigned to this role now see only Southeast and Southwest data.
Adding Column-Level Security (CLS)
Next, suppose you want to limit column visibility within the City table.
You decide to allow access only to:
- City ID
- Sales Territory
Step 1: Open Column Security
- Navigate to Column Security within the role.
- Select the City table.
Step 2: Restrict Columns
Deselect all columns except:
- ID
- Sales Territory
Save the configuration.
Users can no longer see or use restricted columns in:
- Reports
- Semantic models
- SQL queries
- Excel connections
Testing the Security in Reports
Consider a report that originally includes:
- A bar chart showing Sales by Customer
- A column chart showing Sales by Territory
- A card visual showing Total Sales
Original total sales equal 41 billion.
With the new security configuration:
- The Customer table is removed entirely.
- The Sales by Customer visual disappears.
- Only Southeast and Southwest appear in the territory visual.
- The total updates accordingly, for example, 13 billion.
The report dynamically reflects lakehouse security settings.
How Security Flows to Semantic Models and Other Tools
One of the most powerful aspects of OneLake Security is centralized enforcement.
Security defined in the lakehouse applies to:
- Semantic models
- Reports
- SQL endpoints
- Excel connections
- Any downstream artifact
If a user accesses the semantic model directly and builds a new report:
- The Customer table does not appear.
- Restricted columns are unavailable.
- Only permitted territories are visible.
Security is enforced at the data source.
Best Practices for OneLake Security
Design Security Early
Define roles and data access requirements during the architecture phase rather than after publishing reports.
Use Security Groups
Assign Entra ID security groups instead of individual users. This improves maintainability and scalability.
Be Careful When Removing Tables
Completely removing a table may break visuals. Consider whether filtering is more appropriate than full object removal.
Test With Real User Accounts
Always validate:
- Totals
- Visual behavior
- Drill-through actions
- New report creation
Security must work in all access scenarios.
OneLake Security vs Traditional RLS in Power BI
| Feature | Traditional RLS | OneLake Security |
|---|---|---|
| Defined In | Semantic Model | Lakehouse |
| Scope | Single Model | All Downstream Artifacts |
| Object-Level Security | Limited | Supported |
| Column-Level Security | Limited | Supported |
| Centralized Governance | No | Yes |
This represents a major architectural advancement for enterprise data platforms.
Final Thoughts
OneLake Security in Microsoft Fabric brings together Object-Level Security, Row-Level Security, and Column-Level Security into a single centralized interface.
By defining security at the lakehouse level, organizations gain:
- Simplified governance
- Reduced duplication
- Consistent enforcement
- Enterprise-grade scalability
If you are building solutions in Fabric, this feature should be part of your core security strategy.
For deeper learning and structured guidance, explore professional training
