Fabric’s second European conference didn’t just showcase new toys; it tightened the platform’s governance spine. Microsoft moved OneLake Security into full preview and added a Secure tab to the OneLake catalog—a single place to see and manage data‑level permissions across items. That elevates lake‑native RBAC from a feature to a first‑class control surface, so product teams can set access once, at the path where the bytes live, and have it enforced consistently.
The model that finally matches how you build
Control plane ≠ data plane.
Workspace roles (Admin/Member/Contributor/Viewer) decide who can manage the item. OneLake Security decides who can read which folders/tables inside the item, and can add row‑level and column‑level rules for the tables you include in a role. It’s deny‑by‑default: unless you’re in (or virtually in) a role, you see nothing.
A few truths that matter in real projects:
- Opt‑in, per item—and it’s a one‑way switch. Enabling the preview on a Lakehouse creates a DefaultReader role to keep existing readers working; you can tighten or delete it as you roll out your own roles. The toggle can’t be turned off after enablement.
- Writers bypass lake‑RBAC. Admin/Member/Contributor (i.e., users with Write) read regardless of OneLake roles; put consumers in Viewer (or item‑share them) if you want OneLake Security to be the gate.
- “Most permissive wins.” If a person belongs to multiple OneLake roles, the broadest role applies; design roles to avoid accidental overrides of RLS/CLS.
Where “folders” do—and don’t—mean security
Workspace “folders” are for organizing items. Data lives inside items, under /Tables (Delta tables) and /Files (files), and this is where OneLake Security attaches—schemas, tables, and directories are all securable boundaries because, in OneLake, tables and schemas are folders. For programmatic access across workspaces, use the stable GUID path form:https://onelake.dfs.fabric.microsoft.com/<workspaceGUID>/<itemGUID>/<path>.
Shortcuts, clarified
Shortcuts are zero‑copy pointers. Security hinges on whose identity reaches the target and where you put lake‑RBAC.
| Target | Auth model | Whose identity hits the target? | Where you secure | Useful nuance |
|---|---|---|---|---|
| OneLake ➜ OneLake | Passthrough | The caller’s identity | On the target path (you can’t secure the internal shortcut itself) | Identity won’t pass through; use SQL User identity mode or Direct Lake on OneLake. |
| OneLake ➜ External (ADLS/S3/GCS/Dataverse) | Delegated | A connection credential | On the shortcut path (and subpaths) | For Spark/API access to external shortcuts, users also need Fabric Read on the item that hosts the shortcut. |
Microsoft’s refreshed shortcut doc spells this out and adds the SQL/TDS caveat explicitly, including the “owner identity” behavior when you read via delegated SQL paths.
SQL endpoint modes now have an official playbook
When you query a lakehouse through its SQL analytics endpoint, choose how security is enforced:
- User identity mode: the endpoint passes the caller to OneLake; table access is governed by OneLake roles. SQL
GRANT/REVOKEon tables is ignored in this mode; use OneLake RLS/CLS/OLS instead. - Delegated identity mode: the endpoint runs as the item owner; table access is governed entirely by SQL permissions (GRANT/REVOKE, SQL‑RLS/CLS/DDM). Identity does not passthrough to OneLake.
That’s why internal shortcuts can “feel delegated” if you read them via the wrong path—and why the fix is to use User identity or Direct Lake on OneLake.
Materialized Lake Views (MLVs): declarative curation that plays nice with security
What they are. MLVs let you publish curated, lake‑native tables with a single Spark SQL statement (plus optional constraints that either DROP bad rows or FAIL the run). Fabric maintains lineage, schedules refresh, and surfaces a quality report. Today’s preview is Spark SQL‑authored and full‑refresh per view; cross‑lakehouse execution isn’t supported yet.
Because MLVs materialize as Delta tables in your Lakehouse, you secure them exactly like any other table: object‑level grants on the folder/table, plus RLS/CLS in the same OneLake role. Pair that with the right Direct Lake flavor (next section) and your security story stays lake‑centric end‑to‑end.
Direct Lake: pick the flavor that matches your governance
Two similar names, very different implications:
- Direct Lake on OneLake reads Delta files directly from OneLake, isn’t coupled to the SQL endpoint, and never falls back to DirectQuery. It aligns cleanly with OneLake Security and identity passthrough.
- Direct Lake on SQL routes through the SQL endpoint and can fall back to DirectQuery—useful for SQL views, but you inherit that endpoint’s mode (User vs Delegated) and its security semantics.
If you expect lake‑level RLS/CLS to bite everywhere, prefer Direct Lake on OneLake for your semantic models.
How this makes fully secure, dynamic products practical
- Multi‑tenant from one fact table. Land
salesonce, attach a role per tenant with an RLS predicate ontenant_id, and hide PII with CLS. Spark, SQL (User identity), and Direct Lake on OneLake all resolve to the same filtered surface because enforcement happens at the lake. - Curated “Gold” without a warehouse view tier. Express your steady‑state projection as an MLV, with constraints that guard quality. Your semantic model reads a lake‑native table, so you keep the performance and unify governance at the path.
- Producer/Consumer via internal shortcuts—no shadow ACLs. Consumers see the shortcut, but only users granted on the Producer’s target path can read. If you observe “delegated” behavior, you’re likely on Direct Lake over SQL or TDS in Delegated mode—switch the path/mode to restore passthrough.
- Federating external data safely. Point a shortcut at S3 or ADLS with a managed connection, scope OneLake roles to the shortcut path, and keep cloud credentials out of user hands. Remember: Spark/API readers also need Fabric Read on the hosting item to resolve the connection.
Platform changes from FabCon you can lean on
- Secure tab in OneLake catalog for centralized role visibility and management, and OneLake Security in full preview.
- Network guardrails (workspace‑level Private Link GA, Spark outbound protection GA, workspace IP filtering preview) and OneLake diagnostics to capture workspace data activity and storage ops into a lakehouse—useful complements to data‑plane RBAC.
Key Points!
- OneLake Security is opt‑in per item and can’t be turned off once enabled; default role DefaultReader keeps legacy access until you replace it. Writers bypass OneLake RBAC; Viewers and item‑shares are governed.
- Shortcuts: internal are passthrough (secure the target); external are delegated (secure the shortcut), and Spark/API requires Read on the hosting item. SQL/TDS delegated paths and Direct Lake over SQL won’t pass the user’s identity.
- MLVs: Spark SQL only and full‑refresh per view; constraints support
ON MISMATCH DROP|FAIL; cross‑lakehouse execution isn’t available yet.
Bottom Line
The combination of OneLake Security + Direct Lake on OneLake + Materialized Lake Views finally gives Fabric a “least‑surprise” posture: define access at the lake path, ship curated surfaces as tables, and let every supported engine agree on what a user can see. The FabCon Secure tab just makes the operating model visible. That’s how you build dynamic products that stay safe—without duct‑taping per‑engine policies.
EduDataSci - Educating the world about data and leadership 