OneLake Security Deep Dive

As promised in my Fabric security overview article and timed with the recent official GA announcement of OneLake security, this article we are going into OneLake security and workspace/item-level security. We will touch on managed roles, the SQL analytics endpoint, table/folder-level security, RLS/CLS, current limitations, and (most importantly) how these primitives shape how you should architect and operate your Fabric data platform. Note: OneLake security currently applies to Lakehouses (Read/Write), Mirrored Databases (Read), and Databricks Mirrored Unity Catalog (Read).

OneLake Security

Workspace roles

Workspaces roles are the broadest security boundary within a Fabric capacity to enforce access control. Roles can be assigned to users or security groups within your tenant. The following roles are applied at the workspace level: Admin, Member, Contributor, Viewer.

The most important thing to note when it comes to workspace roles and OneLake security is that workspace Admin, Member and Contributor roles automatically grant Write permissions and override OneLake security Read restrictions. This is important when we get to OneLake security, as OneLake security only meaningfully restricts Viewers and users granted ReadAll on an item — the higher roles still see eveything. This means the workspace itself is the real hard security boundary and OneLake security is the fine-grained surface on top of it. Apply the principle of least privilege at the workspace layer first, as they grant very broad access. See here for details on the permissions grated at each role.

Data access control model

OneLake security uses RBAC to manage permissions. Each role has:

• Type: GRANT, DENY (only GRANT is available today)
• Permission: actions allowed/disallowed — Read or Read/Write
• Scope: OneLake data affected — all data or selected tables, folders, or schemas within a supported item
• Members: who to apply the role to — Entra identities including users, security groups or service principals / managed identities

For member assignment, you can manually define individuals and members or create virtual memberships with permission groups. Virtual membership dynamically adjusts based on the Fabric item permissions of the users — this is a better long-term solution when you’re thinking about scalability. You must have Fabric Write or Reshare permissions (usually workspace Admin or Member) to create managed roles.

Workspace roles & OneLake Security

On top of control plane data access, workspace roles provide default access levels to data items by using OneLake security default roles. Each supported item is provisioned with default OneLake security roles that mirror traditional workspace-level data access. The most common is DefaultReader, which uses virtualized membership that grants Read to users who have ReadAll on the item. See below for default role types and their associated permissions by item type.

When you add a user to a more granular custom data access role, make sure you remove them from the DefaultReader role, so they don’t maintain full data access. Alternatively, delete or modify DefaultReader when you create your first restrictive role. Make this a standard step in your item-provisioning runbook.

Table and folder-level (object-level) security

OneLake security roles can grant access to tables and folders in supported items. For a folder to be treated as a table:

1. It must sit under Tables/ (and in a valid schema folder for schema-enabled items).
2. It must contain a _delta_log with valid JSON.
3. It must not include child shortcuts.

If any of these fail, table-level security denies access entirely. Other behavior that must be considered and designed around:

• Inheritance: Once permissions are granted on a folder, it inherits to every child, including subfolders that fall inside shortcuts. There is no way right now to break inheritance on a child.
• Listing shortcuts: Listing a directory returns all internal shortcuts regardless of the user’s access on the shortcut target — access is only checked at open.

Item-level security

You can configure item-level permissions independently of workspace roles by sharing an item or via the manage permissions pane on the item. A user’s effective access is the combination of what they get from the workspace and any direct item shares. You can grant item-level access two ways: Share (quick path, defaults to Read plus optional Reshare/Build add-ons) or Manage permissions (full control, including removing inherited workspace access). The matrix below summarizes each permission and what it lets a user do.

OneLake Security on SQL analytics endpoint

To use OneLake security with the SQL analytics endpoint you must switch the endpoint to User identity access mode (one-time per endpoint). There are two access modes with entirely different governance models:

• User identity mode: manage security centrally with consistent Entra enforcement. Uses a passthrough Entra authentication where access is determined based on the security rules defined within the OneLake item, not by any SQL-level GRANTs.
• Delegated identity mode: all access control is defined and enforced at the SQL engine layer. OneLake security roles and access policies are not applied.

When we think about open architectures, unifying data, and federated architectures, user identity mode takes the cake. Entra-based enforcement provides consistent governance across Power BI, Spark, Lakehouse, and SQL. If you have workload with SQL-native semantics or legacy T-SQL tooling, then you could use delegated identity. I would, however, explore ways to modernize this architecture to Entra-based auth.

Get Alipouw’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

One core security gotcha is with security sync in user identity mode: renaming/deleting a column referenced by an RLS/CLS rule puts the database into an error state until the policy is fixed. Spark/notebook code referencing the renamed column will also fail until updated. Build a change-management discipline around schema evolution.

Shortcut security

There are two authentication models for shortcuts to authorize data access:

• Passthrough shortcuts: the caller’s identity is evaluated against the shortcut target.
• Delegated shortcuts: a stored credential is used to access the target; the caller is evaluated against OneLake security on the shortcut

Internal shortcuts (OneLake to OneLake) are always passthrough. You don’t need to configure any permissions on the shortcut. Permissions cannot be defined on the shortcut itself. You must set permissions on the target folder in the producer item. This means the producer item is always the security authority and the consumer-side shortcuts cannot loosen or tighten that.

Identity passthrough breaks for Power BI DirectLake over SQL and SQL analytics endpoint in delegated identity mode. For both, the item owner’s identity (not the caller’s) is used at the shortcut target. To preserve passthrough, ensure you use DirectLake over OneLake mode or T-SQL in user identity mode. Additionally, if the target item type doesn’t support OneLake security, fallback is a ReadAll permission check.

Delegated shortcuts are for external sources, such as ADLS Gen2, S3, Iceberg, Dataverse, etc. See a full list of external shortcuts here. A user accessing an external shortcut requires Fabric Read permission on the target item. An internal shortcut pointing to an external shortcut still requires the user to follow to the original external shortcut’s access rules. See full documentation here. See here to create an internal shortcut and subpages on creating external shortcuts.

RLS/CLS

Row and column level security (RLS/CLS) can be applied to delta tables only and primarily affect Viewers*. This is where your end-to-end security architecture makes a difference. You must consider how to apply permissions with RLS/CLS, at the item/folder-level, at the workspace-level, how networking should be configured, as well as information protection and DLP with Purview. Reference this article for a full overview of E2E security architecture in Fabric.

Some key constraints to consider for both RLS and CLS include:

• RLS: Delta only; ≤1,000 chars per predicate; limited SQL surface. No joins, no functions, no subqueries.
• CLS: Delta only; at least one column must remain visible; engines disagree on SELECT * behavior (Spark filters silently, SQL endpoint / semantic models block the query). In the SQL endpoint, CLS resolves via intersection (deny-wins) while in Spark it’s a union — the same user can see different columns in different engines.
• You cannot combine an RLS-only role and a CLS-only role for the same user. You must put both in a single role.
• Non-authorized engines (e.g., raw ADLS API): RLS/CLS tables are fully blocked, not filtered.

*Although OneLake security is targeted to Viewers, there are some exceptions where higher-privilege roles are still affected:

• RLS in user identity mode: When a downstream consumer accesses producer data via DirectLake-over-SQL or a SQL endpoint in Delegated identity mode, the item owner’s identity (not the caller’s) is evaluated against the producer’s roles. A downstream workspace Admin can therefore be filtered by an upstream RLS rule they aren’t subject to.
• CLS schema inspection: CLS does not protect against schema introspection meaning column names remain visible in metadata views (defined in the limitations above too).
• Security Sync Failure: if the security sync fails, all users of the affected roles may have their access restricted
• Workflow restriction in User’s identity mode: SQL GRANT/REVOKE on tables is ignored. Admins who try to manage permissions via T-SQL must instead author OneLake security roles.

Architectural implications

Okay so, this is all fine and dandy, but why should you care, and how can you use this implement a secure and functional architecture at scale?

1. Adopt a producer/consumer (hub-and-spoke) workspace model: Admin/Member/Contributor always see all data. Sensitive data must live in workspaces where consumers are Viewers only. Producer workspace items hold the authoritative roles; consumer workspace items consume via shortcuts in User identity mode. Bias to item-level Read sharing over assigning Workspace Viewer broadly — it’s easier to revoke and audit per dataset.
2. DefaultReader is given to everyone with ReadAll: delete or restrict it as a standard provisioning step.
3. Identity strategy must be security-group-only. Distribution lists don’t resolve; nested groups don’t traverse the producer to consumer boundary (cross-tenant/cross-workspace Entra group resolution); B2B needs tenant configuration.
4. Engine selection is a security decision. DirectLake-over-SQL and SQL Delegated mode break identity passthrough. Standardize on DirectLake-over-OneLake and SQL User’s identity mode.
5. Lakehouse layout must be schema-enabled and shortcut-aware. For OneLake security to work, keep shortcuts out of Tables/. Non-schema lakehouses break data preview for secured tables. This is critical for gold-layer tables and is core to medallion architecture design.
6. Service principals must use OneLake ReadWrite roles: Scope service principals to OneLake ReadWrite roles or item-level permissions; avoid granting them workspace Admin/Member, which bypasses OneLake security.
7. RLS/CLS rules: Combine both in one role per domain, and sensitivity-level.
8. Gaps require additional security layers: Read audit gaps, no Data Share integration, no Dynamic Data Masking (DDM). Leverage Purview (sensitivity, DLP, Activity Explorer), Defender for Cloud Apps, and Fabric network security / Private Links.

Take the above along with our E2E Security Overview, and data strategy section of the agent builder article to get started on building your security foundation in Microsoft Fabric. Hope this was helpful!