Securing a Microsoft Fabric Estate: Workspace Roles, OneLake Security, RLS and OLS

The fastest way to fail a Fabric security review is the thing that felt efficient at the time: handing out workspace Admin or Contributor to everyone because it was quicker than thinking about who needs what. That collapses a layered security model into a single flat one, and it is almost impossible to unwind on a live estate.

Security in Microsoft Fabric is not a switch. It is four layers a user passes through before they reach data — Entra groups, workspace roles, OneLake security, and row/object-level security — with sensitivity labels applied over the top. Each layer answers a different question, and each has to be designed, not defaulted.

And it has to be designed in from the start. Retrofitting least privilege after access has been granted broadly, and after sensitive data has already spread, is far harder than building it in — and it is usually forced on you by an audit rather than chosen. So the architect’s job is to design the layers before the pipelines are trusted, not after.

Two access models sit underneath the layers. RBAC — role-based access control — grants access by role: a finance user gets access to the finance workspace because of who they are. It is the backbone of Fabric access, and for most needs it is enough.

ABAC — attribute-based access control — grants access by attribute: a user whose region attribute is UAE sees data whose region attribute is UAE. It handles the cases RBAC cannot express cleanly — access that depends on a match between user and data rather than a fixed role — and it is how you avoid creating a separate role for every region or business unit.

A mature estate uses both: RBAC for the coarse-grained "who can reach this workspace and these items", ABAC and data-level rules for the fine-grained "which rows within it". Knowing when each applies is part of designing security rather than bolting it on.

Start at identity. Microsoft Entra ID groups are the unit of access — you assign access to groups, not individuals, so joining or leaving a team changes access automatically. This is the foundation everything else builds on, and skipping it (assigning access to named people) is what makes access impossible to audit later.

Then workspace roles decide what a user can do in a workspace: Admin manages everything, Member and Contributor build and edit, Viewer consumes. Most people should be Viewers or Contributors; Admin is for the few who genuinely administer. Below that, OneLake security governs access to the underlying data in OneLake, so workspace access does not automatically mean data access.

Finally, data-level security: row-level security decides which rows a user sees (a sales manager sees only their region), and object-level security decides which tables and columns they can see at all (salary is invisible to those without the right). A user passes through all four — Entra group, workspace role, OneLake security, RLS/OLS — before reaching data, with Purview sensitivity labels marking what needs protecting throughout.

Least privilege means giving each user and each service only the access their responsibility requires — no more. In practice that reads as: developers get Contributor, analysts get Viewer, administrators get Admin, and pipelines run under a service principal scoped to exactly what they touch. Nobody gets Admin "just in case".

The test is simple and worth applying to every grant: what breaks if this person or service could not do this? If the honest answer is "nothing they are actually responsible for", the access is too broad. Broad access is not a convenience — it is a standing liability that widens the blast radius of any mistake or compromise.

This is also what makes wider AI access safe. A Fabric Data Agent or Copilot inherits the security of the data it reasons over, so if RLS and OLS are properly designed, natural-language access does not become wider data exposure — a user asking a question in plain English still only gets answers from data they are entitled to see. Least privilege is the reason AI over your data can be opened up without opening up the data.

Automation needs identity too, and it is where over-granting quietly creeps in. Create a dedicated service principal for deployment — not a personal account, not a shared admin — and scope it to exactly the workspaces and actions it needs. A deployment identity that promotes artefacts to QA needs rights in QA, not tenant admin.

The same discipline applies to environment-specific secrets and connections: DEV, QA, UAT and PROD each have their own, managed securely and never hard-coded, so a promotion moves the artefact without moving production credentials into a developer’s hands. Secrets in code and shared admin identities are two of the most common findings in a real Fabric security review.

Handing tenant admin to a service principal because it makes the pipeline "just work" is the automation version of making everyone a workspace Admin — the same mistake, harder to spot. Scope it down, and the estate stays auditable.

Security in Fabric is layered, and the layers only hold if they are designed in from the start: Entra groups at the base, workspace roles above, OneLake security below that, RLS and OLS at the data, sensitivity labels throughout, least privilege as the rule, and scoped service principals for automation. RBAC for the coarse grain, ABAC and data rules for the fine grain.

Do it early and it is straightforward and auditable. Do it late — after everyone is an Admin and sensitive data has spread — and it is a painful, risky retrofit usually triggered by a failed audit. The choice of when is the real decision, and the architect makes it at design time, not after the incident.

We build Microsoft-first by default, and the same layered discipline maps to a Databricks estate through Unity Catalog’s row- and column-level security and access model. The controls differ; the principle does not — least privilege, designed in, in layers.