Microsoft Fabric: OneLake Security Guide

Key insights

• OneLake Security — Centralizes access control at the lakehouse storage layer so you define permissions once and they apply to SQL endpoints, Spark, Direct Lake, semantic models, and AI agents.
  In the video, Reza Rad demos how a single security definition reduces duplicated rules and enforcement gaps.
• Upstream security — Apply rules as close to the data as possible so every workload inherits the same enforcement.
  This prevents bypasses when tools or notebooks query data outside the semantic model.
• User Identity Mode — OneLake Security requires lakehouses and warehouses to use User Identity Mode rather than Delegated Identity Mode.
  Switching the SQL analytics endpoint to user identity ensures queries run with the caller’s identity and respect OneLake rules.
• Roles & scopes — Create roles in the Manage OneLake security pane, assign permissions (Read or ReadWrite), and scope them to All data or Selected data (tables, folders, files).
  Add members, publish the role, and confirm it propagates to the workloads you use.
• Row & column rules — You can add row-level predicates (SQL filters) and column-level restrictions inside OneLake roles to limit what users see.
  The demo shows how to create these rules and validate access with a live user sign-in and queries.
• Semantic Model RLS — RLS at the semantic model only protects access through that model and can be bypassed by other consumers.
  OneLake Security enforces policies across all entry points, and it integrates with Direct Lake models so governance stays consistent.

Microsoft Fabric expert Reza Rad (RADACAD) [MVP] published a clear, step-by-step YouTube walkthrough that explains how to configure OneLake Security and why applying security at the storage layer is often the better architectural choice. In the video, he contrasts the new centralized approach with the older habit of defining Row-Level Security repeatedly in multiple layers, which often led to inconsistent enforcement and extra maintenance. Moreover, Rad demonstrates the full setup from prerequisites to a live validation, making the process tangible for admins and architects. Consequently, the video serves as both a how-to guide and an argument for rethinking where security belongs in a Fabric estate.

What the video covers

First, Rad outlines the motivations behind OneLake Security, explaining how a single definition can follow data across workloads such as SQL analytics endpoints, Spark notebooks, and Direct Lake semantic models. Then, he steps through prerequisites including the need for schema-enabled lakehouses and the proper workspace permissions that let administrators manage security. He also explains the critical setting that lakehouses and warehouses must use User Identity Mode instead of Delegated Identity Mode for OneLake policies to apply. Finally, the video includes a live demo that shows role creation, scoping, and row- and column-level rules in action, which helps viewers confirm the end-to-end flow.

Why OneLake Security changes the model

Rad emphasizes that security defined at the semantic model level stays limited to that layer, so any tools that bypass the semantic layer can bypass those rules. In contrast, OneLake Security attaches access control to the storage layer, so the same role and rules apply whether a user queries via SQL, runs a notebook, or accesses data through AI agents. Therefore, enforcement becomes universal and consistent, which reduces governance gaps and the risk of accidental exposure. Additionally, this shift simplifies management because teams maintain one set of rules instead of four separate configurations across endpoints and models.

However, Rad also points out tradeoffs and practical constraints when moving security upstream. For instance, organizations must ensure that all their Lakehouses and Warehouses run in User Identity Mode, and older items might require an explicit switch in settings. Moreover, applying security in-storage shifts some complexity into identity and authentication configuration, which demands careful testing and single sign-on validation. As a result, teams must weigh the operational work required to reconfigure endpoints and retrain administrators against the long-term gains in consistency and reduced duplication of effort.

Key steps and demo highlights

In the demo, Rad shows how to open the Manage OneLake security pane, create roles, and pick either All data or Selected data scopes, then assign users or groups to those roles. He walks viewers through creating Grant permissions such as Read and ReadWrite, and demonstrates how to add row-level predicates for fine-grained control. Consequently, viewers get a practical view of how a Default Reader Role behaves and why it exists as a baseline permission. The live validation confirms that user identity flows properly from the client through the SQL endpoint into OneLake, provided the identity mode is correctly configured.

Rad also covers common pitfalls that administrators encounter during setup. For example, forgetting to switch an endpoint to User Identity Mode can result in queries running under a delegated account and bypassing OneLake enforcement. In addition, schema requirements for lakehouses mean some legacy assets may need migration or modification before rules apply. Therefore, the video encourages admins to check prerequisites, run small tests first, and validate role behavior across the different tools their teams use.

Tradeoffs, challenges, and governance considerations

Adopting OneLake Security reduces duplicated policy definitions and cuts the number of failure points, but it also centralizes responsibility, which can create bottlenecks if governance processes are immature. Moreover, teams must balance the desire for centralized control with the need for delegated administration; in other words, central roles simplify consistency but require clear processes for role proposals, approvals, and audits. Rad suggests implementing staged rollouts and automated testing to mitigate risks while enabling teams to adopt the model gradually.

Performance and tooling compatibility also surface as tradeoffs in the video. While storage-level enforcement ensures broad coverage, it can introduce subtle differences in query behavior or latency depending on how identity flows are handled by endpoints. Thus, Rad recommends that architects test representative workloads and document exceptions where semantic model-level logic remains necessary. Ultimately, organizations should aim for a hybrid plan that leverages OneLake for broad coverage while reserving semantic model rules for use cases that require model-specific logic.

Implications and recommendations

In closing, Rad urges organizations to view OneLake Security as an opportunity to modernize data governance and reduce operational overhead. He recommends checking identity modes, converting new lakehouses and warehouses to the correct mode by default, and using staged tests to validate enforcement across SQL, Spark, and BI workloads. For teams that want control with less duplication, the approach offers clear benefits, yet it requires deliberate planning, testing, and governance changes to succeed. Consequently, the video is a practical resource that pairs a technical walk-through with balanced advice on tradeoffs and challenges.

Keywords

OneLake security Microsoft Fabric, Set up OneLake security step-by-step, OneLake access control setup, Microsoft Fabric security best practices, OneLake permissions tutorial, Why not Semantic Model RLS, Fabric OneLake row-level security alternatives, Configure OneLake data protection