Fabric Security and Governance: Workspace Roles, RLS, and OneLake Access

Fabric evaluates access in three layers, and a user needs a path through all of them to reach data: the workspace layer (roles granted on the whole workspace), the item layer (permissions granted on a single Lakehouse, Warehouse, notebook, or report through sharing), and the data layer (RLS, CLS, OLS, dynamic data masking, and OneLake security roles that filter what a permitted user sees inside an item). A workspace role is the broadest grant — it applies to every item in the workspace, including items created later. Item permissions are the surgical alternative: you share one item with a user who has no workspace role at all, and they see only that item. Sharing never creates workspace membership.

The layers combine additively for access but each answers a different question. Workspace roles answer "what can you do in this workspace?" Item permissions answer "which items can you touch?" Data-level security answers "which rows, columns, and files can you see once you are inside?" Because sharing is additive, it can only add rights: sharing an item with someone who already holds a workspace role cannot take away anything that role grants. A requirement like "a user must query only one warehouse" is an item-sharing problem, "analysts must see only their own region's rows" is a row-level security problem, and "the finance team manages all content in the workspace" is a workspace-role problem.

One principle governs the whole model: grant the least privilege at the narrowest layer that satisfies the requirement. Giving someone the Viewer workspace role when they need one report exposes every item in the workspace; sharing the single report does not.

Fabric has exactly four workspace roles, and their capabilities nest: each role can do everything the roles below it can. Admin owns the workspace itself — only Admins can change workspace settings, delete the workspace, connect it to Git, and add or remove other Admins. Member manages people below Admin level: it can add users as Member, Contributor or Viewer, share items and allow resharing, and create and edit OneLake security roles. Contributor is the working engineer's role: create, edit, and delete items, run notebooks and pipelines, and write data — but no rights to manage who else has access. Viewer is read-only: view items and query data through the SQL analytics endpoint (subject to any SQL-level security), with no OneLake or Spark access to the underlying files unless a OneLake security role grants it.

Two rows in that table decide most access scenarios. First, Contributor cannot share or manage access — a developer who must build content but must not grant access to others is a Contributor, not a Member; someone who must also onboard colleagues or maintain OneLake security roles needs Member. Second, Viewer reads through SQL, not through OneLake — a Viewer querying a Lakehouse uses its SQL analytics endpoint and is subject to any T-SQL security defined there. A Viewer reaches the Delta files from Spark only when a Member or Admin adds them to a OneLake security role, and then only the tables or folders that role covers. That distinction is the hinge for the security-boundary discussion later in this lesson.

Roles are assigned to individual Microsoft Entra ID users, security groups, Microsoft 365 groups, or distribution lists. Prefer groups: assigning roles to groups keeps access reviews manageable and makes onboarding a membership change instead of a Fabric change.

Item-level access lets a user reach a single item without holding any workspace role, and it is how you serve consumers outside the engineering team. Sharing always grants Read, which lets the recipient connect to the item and see its metadata but no data. The share dialog then offers extra boxes that map to further item permissions:

Resharing is not a box you can tick on a warehouse share: Reshare cannot be granted on its own, and share recipients cannot pass a warehouse on — the ability to share comes from the Admin and Member workspace roles.

Older material lists Build as a warehouse share option. That came from the warehouse's default semantic model; since default semantic models were decoupled from warehouses, Build is a permission you grant on a semantic model (to let people build reports on it), not a box in the warehouse share dialog.

The Read/ReadData/ReadAll split is the load-bearing distinction. A recipient with only Read on a warehouse can connect but sees no data until you grant objects with T-SQL (GRANT SELECT) — this is the deny-by-default pattern for fine-grained SQL security, and anything created later stays closed until granted. Granting ReadData opens all tables through SQL, where RLS, CLS, OLS, and masking still apply; it is allow-by-default, so hiding objects needs DENY statements that must be repeated for every table added later. Granting ReadAll opens the raw Delta files — and SQL-defined security does not travel to file reads, so ReadAll bypasses RLS, CLS and masking. On a lakehouse, OneLake security roles can scope ReadAll users (see below); on a warehouse there are no OneLake security roles, so ReadAll means the whole table.

Item permissions also come into play within a workspace: sharing is additive on top of roles, and some permissions (like Build on a semantic model) may need to be granted even to users who can already see the item. When external analysts must query warehouse tables but never see the files, share with ReadData and withhold ReadAll.

RLS, CLS, and OLS are T-SQL controls defined in a Warehouse or in a Lakehouse's SQL analytics endpoint, and they filter what a user sees when querying through SQL. Row-level security restricts which rows a query returns. You implement it with a schema-bound inline table-valued function that encodes the predicate — typically comparing a column to USER_NAME() or looking the caller up in a mapping table — and bind it with CREATE SECURITY POLICY as a filter predicate on the table. From then on, every SELECT from that table is silently filtered per caller.

A security policy filters every user, including dbo and workspace Admins, Members and Contributors — unlike dynamic data masking, elevated roles get no automatic exemption. If engineers or auditors must see all rows, write that exemption into the predicate (for example, return 1 when the caller is in an exemptions table or holds a database role). Because the predicate function is schema-bound to the policy, changing it means DROP SECURITY POLICY, ALTER FUNCTION, then re-creating the policy; ALTER ANY SECURITY POLICY is the permission to manage policies, not a way to see through them.

Column-level security restricts which columns a user can select. It is column-scoped grants: GRANT SELECT ON dbo.Customers (CustomerID, Name, Region) TO [analyst@contoso.com] allows those three columns and nothing else. It is a hard block, not obfuscation: a query that touches an ungranted column fails with a permission error, and that includes SELECT *, which expands to every column. Granting UNMASK does not help — it belongs to masking and grants no SELECT.

Object-level security works one level up with GRANT, DENY, and REVOKE on whole tables, views, schemas, stored procedures, and functions. A common composite pattern: share the warehouse with Read only, expose curated views, and grant SELECT only on the views — new base tables stay invisible without further work.

Know the enforcement boundary cold

These controls live in the SQL engine, so they protect the Warehouse and the SQL analytics endpoint — and nothing else. A user who reaches the same Delta tables through Spark, a OneLake API or a OneLake shortcut is not filtered by a security policy, not limited by column grants and not masked. Warehouse RLS, CLS and OLS are not translated into OneLake: a shortcut that points at a warehouse table exposes the full table to anyone allowed to read the shortcut. To keep a consumer team filtered, keep it on the SQL path (Read plus ReadData, no ReadAll) rather than letting it shortcut the files.

Power BI follows the same boundary. A Direct Lake on SQL semantic model falls back to DirectQuery when the warehouse or endpoint has RLS or CLS, so the report is still filtered by the SQL engine (that is the default Automatic Direct Lake behaviour; a model set to DirectLakeOnly fails those queries instead of falling back). A Direct Lake on OneLake model reads the Delta files, has no DirectQuery fallback, and does not apply warehouse T-SQL RLS — it needs its own semantic-model roles (DAX filters) or OneLake security. Semantic model RLS and engine RLS are configured separately and do not synchronize. Finally, a Lakehouse's SQL analytics endpoint is read-only for data but does accept security DDL, so you can define RLS/CLS/OLS over Lakehouse tables for SQL consumers (in its default access mode — see the next section).

Dynamic data masking (DDM) obfuscates sensitive column values in SQL query results for non-privileged users without changing the stored data. You attach a masking function to a column with ALTER TABLE ... ALTER COLUMN ... ADD MASKED WITH (FUNCTION = '...'). Four functions exist:

Masking applies to users who lack the UNMASK permission. Workspace Admins, Members, and Contributors hold CONTROL on the database, which includes UNMASK, so they always see real values; DDM is meaningful mainly for Viewers and ReadData-style share recipients. Two permissions are easily confused: UNMASK lets a user see real values (database-wide, or scoped to a schema, table, or column), while ALTER ANY MASK lets a user add, change or drop masks without revealing the data.

Know DDM's limits. It is presentation-layer obfuscation, not encryption: the plaintext is stored and processed normally, and a user with ad-hoc query rights can often infer masked values with predicate probing (WHERE Salary > 100000 still filters on real values). It exists only in the SQL engine, so a user who reads the same Delta table through Spark or a OneLake API — for example a ReadAll share recipient in a notebook — gets the stored values, unmasked. And it is not available on a SQL analytics endpoint running in user identity mode. Choose DDM to keep casual eyes off PII in shared query surfaces; choose CLS to block a column entirely; never treat DDM as a substitute for access control.

OneLake security controls access to the data itself — tables and folders in a lakehouse — for users who come in through OneLake APIs, Spark notebooks, or (in user identity mode) the SQL analytics endpoint. It is the layer that closes the gap T-SQL security leaves open for file reads. You define OneLake security roles that grant Read on specific tables or folders (for example, only Tables/gold or a subfolder of Files), optionally add row filters and column restrictions to a role, and assign users or groups to it. Roles are grant-only: there is no deny, and a user in several roles gets the union of them. Workspace Admins and Members create and edit roles; Contributors cannot.

The audience is the most tested fact: OneLake security roles apply only to Viewers and to users who hold Read or ReadAll on the item through sharing. Admins, Members and Contributors are not restricted by them — those roles read all data in the workspace, with one documented exception: OneLake row-level security rules are enforced for them too when they query through a SQL analytics endpoint in user identity mode (see the access-modes section). If some engineers must not read a raw or sensitive zone, the fix is a separate workspace (or not giving them a write role), not a OneLake role.

DefaultReader. Every lakehouse with OneLake security has a built-in DefaultReader role that grants all data to every user with ReadAll. Turning on OneLake security therefore changes nothing for ReadAll users until you narrow it: edit or delete DefaultReader, or remove users from it, and then put them in roles scoped to the tables or folders they need. A Viewer without ReadAll has no OneLake access until a Member or Admin adds them to a role; once added, they can read the granted tables from Spark (OneLake security in Spark requires a recent Fabric Spark runtime — check the current requirement in the OneLake security documentation).

OneLake security roles are available on lakehouses and mirrored items, not on warehouses — a warehouse relies on T-SQL security, and its RLS/CLS/OLS are not carried into OneLake. That matters for shortcuts: a shortcut to another lakehouse's table is governed by the OneLake security of the target, but a shortcut to warehouse data sees the full table, because warehouse SQL security does not exist at the file level. The working model: SQL security guards the SQL door, OneLake security guards the file door, and a complete design covers both doors.

A lakehouse's SQL analytics endpoint has a data access mode that decides which security system governs table reads through SQL: delegated identity (the default) or user identity. The choice matters as soon as a lakehouse has OneLake security roles, because the two modes enforce different rules.

Choose delegated mode when DBAs must author everything in T-SQL or when masking is required; choose user identity mode when you want one set of OneLake rules to be enforced the same way for SQL and Spark consumers. In user identity mode the OneLake roles decide what Viewers and Read/ReadAll users see — a DBA's GRANT SELECT on a table has no effect, so a Viewer who needs one table is added to a OneLake role scoped to that table. RLS rules defined in OneLake security are enforced for every user in this mode, including Admins, Members and Contributors, while the role's table grants still only scope Viewers and Read/ReadAll users.

Switching to user identity mode is done by a workspace Admin or Member and is disruptive: existing SQL roles are deleted, table-level GRANTs and T-SQL RLS/CLS stop applying, inline metadata objects — all table-valued and scalar-valued functions, not only security predicates — are removed (switching back to delegated mode removes them too), and every SQL analytics endpoint in the workspace is briefly unavailable — running and queued queries are cancelled. Create the equivalent OneLake roles first and switch outside business hours.

Governance in Fabric answers three questions: how sensitive is this item, can I trust it, and who touched it?

Sensitivity labels

Sensitivity labels from Microsoft Purview Information Protection classify items using the tenant-wide label taxonomy your organization defines (Public, General, Confidential, Highly Confidential, and so on). A label is applied to a whole item — a lakehouse, warehouse, semantic model or report — not to individual tables or columns. It follows the data downstream through inheritance to derived items. Labels can be applied manually by item owners, mandated by tenant policy, or inherited from upstream sources; the feature must be enabled in the tenant admin portal with appropriate licensing.

A label is classification plus protection, not a query permission: it does not change who can read the item inside Fabric. Its protection travels only on supported export paths — export to Excel, PDF and PowerPoint, Analyze in Excel, and downloading a .pbix keep the label and any encryption. Exports to .csv or .txt are not protected, so if labelled data is leaking through CSV exports, the control is the tenant setting that allows export to .csv, not another label.

Endorsement

Endorsement is Fabric's trust signal, with three badges that mean different things:

Anyone can request certification or master data designation; the authorized reviewers apply it. Pick the badge by meaning: Certified is about quality review, Master data is about being the single reference source. Endorsed items surface prominently in the OneLake catalog and search.

Audit logs and OneLake diagnostics

Fabric audit logs record user and administrative operations — item creation, sharing, permission changes, workspace and OneLake security role edits, report views and exports — in the unified Microsoft Purview audit log. Compliance teams search them in the Microsoft Purview portal's Audit solution or with the Search-UnifiedAuditLog PowerShell cmdlet; retention depends on your Purview audit plan. They answer "who shared the warehouse" or "who changed this role", and they live in Purview, not inside the Fabric workspace UI.

OneLake diagnostics answers a different question: who read or wrote which files through OneLake APIs (for example the ADLS-compatible DFS endpoint used by external tools), with caller identity, path and IP. A workspace admin enables it per workspace and chooses a lakehouse to receive the events, which are stored as JSON files that you can query with Fabric engines. The destination lakehouse must be on the same capacity as the monitored workspace. Recording starts only when it is enabled (events can take up to an hour to appear), so it cannot answer questions about earlier activity — past control-plane changes are found in the Purview audit log instead.

Requirements: engineers build and load a Lakehouse; a BI team queries curated tables but each analyst may see only their own region's rows; the analysts must never read raw files; salary data must be hidden from everyone but HR; customer emails are masked for most analysts; auditors need to know who changed access. Here is the layered design.

Workspace layer: engineers get Contributor (they build but do not manage access); the data platform lead gets Admin; a security owner who maintains OneLake roles gets Member; nobody else gets a workspace role. Contributors read all lakehouse data, so raw data that some engineers must not see belongs in a separate workspace. Item layer: share the Lakehouse with the BI team's Entra ID security group with "Read all data using SQL" (ReadData) and without ReadAll — no file-path access.

Data layer: keep the SQL analytics endpoint in delegated identity mode, because masking is required and the DBAs author rules in T-SQL. Create a security policy whose predicate maps USER_NAME() to a region assignment table, with an exemption row for the engineers who validate loads; use column-scoped GRANT SELECT so the salary column is selectable only by the HR group; add email() masking on customer email for the general analyst population. If a Viewer group later needs Spark access to one table, add it to a OneLake security role on that table and narrow DefaultReader.

Governance: apply a Confidential sensitivity label to the Lakehouse so it propagates to downstream reports and supported exports, and disable .csv export if the data must stay protected outside Fabric; have an authorized reviewer certify the gold semantic model; answer auditors from the Purview audit log, and enable OneLake diagnostics if file-level API reads must be recorded from now on. Every requirement maps to exactly one layer — which is the mapping skill DP-700 scenario questions test.