Secure at the Boundary: RBAC, Aggregator Groups, RLS—and what OneSecurity changes

Despite the different semantics, Microsoft Fabric actually uses the same principles as folder security. Fabric makes the security boundary explicit (the workspace) though, which actually makes role design easier, and lighter‑weight, than old folder ACLs.

Why this model “clicks” in Fabric

On a file share, you secure a specific folder and everything below inherits. Fabric keeps the same principle but makes the boundary explicit: the workspace. That clarity replaces “some folder in a ragged tree” with a clear perimeter you can reason about—and it turns role design into a short, durable RBAC map you can automate and audit. Workspaces sit on OneLake and act as independently secured containers, so they’re always the right place to anchor access. 

Domains and subdomains are for organization and delegated governance, not authorization: assigning a domain improves catalog discovery and enables some delegated settings, but doesn’t change item visibility or access. Everyone in the tenant can see the domains list; access still comes from workspace roles and item/compute permissions. 

Folders in a workspace are for structure, not security. They inherit the workspace’s permissions; you don’t manage ACLs per folder the way you did on file shares. 

RBAC at the boundary (and why it’s less work)

Fabric uses four workspace roles—Admin, Member, Contributor, Viewer—assignable to users or groups. If a person is in multiple groups, the most permissive role applies. Nested groups are expanded, so your Entra group hierarchy “just works.” Because the boundary is explicit and there are only four roles, you design once and inherit downward—no ACL sprawl. 

Operationally, changes to workspace access take effect at the next sign‑in, and each workspace supports up to 1,000 users or groups in its roles—another reason to manage at the group level rather than user‑by‑user. 

Mental model: the workspace access list (Role → Group → User) behaves like a closure table. Expand nested membership at the boundary, then everything inside inherits. That’s functionally the same as securing folders at their security boundary—Fabric just makes the boundary explicit (the workspace), while the list above it (the workspace list) effectively is the closure that defines the boundary.

Aggregator groups: scale without sprawl

Most organizations already have persona/job-function groups (e.g., FIN‑Analysts). To avoid repeating the same assignment across many workspaces:

• Create four workspace‑scoped groups and make them your only direct assignments to the workspace: WS-{Domain}-{Subdomain}-{Workspace}-{ADM|MEM|CON|VWR}
• Create aggregator groups per domain/subdomain × role (e.g., AGG‑FIN‑OTC‑VWR).
• Nest persona groups → into the aggregator → into each workspace’s matching WS‑… group.

Because Fabric honors nested groups and highest effective role, everyone flows into the right workspace role—once. You update membership in one place and the change fans out across all the relevant workspaces on the next sign‑in. 

RBAC vs. RLS: what you can reach vs. which rows you see

• RBAC (workspace roles + optional item/compute permissions) answers what you can reach across Fabric.
• RLS (Row Level Security) answers which rows you see after you can reach the model/table.

For Power BI semantic models, RLS applies to Viewers; it doesn’t apply to Admin/Member/Contributor. Keep consumers as Viewers if you expect RLS to govern their result set. 

What OneSecurity changes—and what it doesn’t

Microsoft’s “OneSecurity” vision is landing in Fabric as OneLake security (currently in preview), which unifies data‑plane permissions across engines and adds richer policies at the lake layer. Architecture guidance even calls out “Use OneSecurity to set up data security policies for data assets.” 

What changes:

• One definition, consistent enforcement across engines – Define OneLake security roles on your lakehouse data once and Fabric enforces them consistently across engines (Spark, SQL endpoint, semantic models) to avoid mismatches between file access and compute access. 
• More expressive policies at the lake – In addition to folder/table scoping, row‑level (RLS) and column‑level (CLS) security rules can be defined at the OneLake layer and composed across roles. This extends the “rows you can see” concept beyond semantic models and warehouses to the lake itself. 
• Simplified feature set – OneLake security supersedes the earlier OneLake data access roles feature; existing roles are being upgraded automatically as the preview progresses.
• Helpful defaults – Lakehouses include a DefaultReader role you can edit or remove to fit least‑privilege norms. 

What doesn’t change:

• The workspace is still your first boundary – Security evaluation still goes Workspace → Item → OneLake. OneLake security applies inside that boundary; it doesn’t replace workspace RBAC. 
• Admins/Members/Contributors are not constrained by OneLake roles – OneLake security primarily governs Viewers/readers; builders (Contributor/Member) and Admins retain read/write access to item data. 
• Domains remain organizational, not access – Assigning or moving a workspace between domains still doesn’t grant or revoke access. 
• Your group‑first, bottom‑up design still wins – You still assign workspace roles to groups, and you still scale access via nested Entra groups (personas → aggregators → workspace groups). OneLake security simply lets you tighten read scopes in the data plane for Viewers, when needed. 

Status check (as of July–August 2025): OneLake security is in limited preview and is rolling out to replace data access roles. Keep an eye on the Fabric roadmap and docs for GA scope and any enforcement nuances. 

Where folders & OneLake fit now

Use folders to organize content; they inherit workspace permissions. When Viewers need to browse files, use OneLake security to grant read on just the folders/tables they need—enforced consistently across engines. Builders don’t need this; their workspace role already grants write. 

This is better, and less work than, ACLs

• Explicit boundary → simpler roles – No more guessing which folder in a sprawling tree is “the” boundary. You secure the workspace, full stop. 
• Manage people once – Update a persona group → it flows through the aggregator → into the workspace role. Next sign‑in applies the change everywhere. 
• Predictable inheritance – Folders inherit. Only add OneLake rules when Viewers truly need narrower file/table reads. 

Worked example (end‑to‑end)

Goal: Give OTC analysts Viewer across multiple OTC workspaces, RLS by region, and file‑level reads only under /Tables/Published/.

• Workspace assignments (once per workspace) – WS‑FIN‑OTC‑RevAnalytics‑{ADM|MEM|CON|VWR} and WS‑FIN‑OTC‑BillingOps‑{…} are the only groups assigned to each workspace role.
• Aggregators & personas – AGG‑FIN‑OTC‑VWR nests FIN‑Analysts, REVOPS‑Consumers; each workspace’s WS‑…‑VWR includes AGG‑FIN‑OTC‑VWR. Result: onboarding a new analyst = add to FIN‑Analysts; they inherit Viewer across all OTC workspaces at the next sign‑in. 
• RLS – Keep analysts as Viewers so RLS applies in semantic models; optionally mirror similar row filters in OneLake security RLS for lake‑level queries. 
• OneLake security – Define a role that grants Read on /Tables/Published/ (and applies any needed row/column constraints) for Viewers; builders are Contributors and aren’t constrained by OneLake roles. 

Bottom line

Fabric didn’t change the security principle—it clarified it. Secure at the boundary, inherit downward, and tighten where needed. By making the boundary explicit (the workspace), Fabric makes roles easier to define and maintain. OneSecurity/OneLake security then gives you a consistent, engine‑wide way to fine‑tune what Viewers can read in the lake—including rows and columns—without ever abandoning the workspace‑first RBAC model.