Fabric Security Issues

We’re trying to implement a medallion architecture in Microsoft Fabric and are running into major roadblocks with access control and workspace security inheritance.

Architecture Goals

• We want to set up bronze layer ingestion pipelines in an Ingestion Workspace.
• Shortcut the bronze tables into a separate Curated Workspace, where a different team:
  • Transforms data into silver/gold layers.
  • Builds views and semantic models.
  • Manages data access (eventually with RLS/CLS).
• Ensure the curated team cannot modify raw/bronze layer data but can read from it and build on top.

Current Issues

• Shortcuts Require Access to Source Lakehouse
  • Only lakehouses support shortcuts (not warehouses).
  • To use shortcuts in the curated workspace, users must be granted access to the source lakehouse in the ingestion workspace.
  • This defeats the purpose of separating roles and delegating security management to the curated team, because we can’t isolate source data access.
• Workspace Role Overrides Lakehouse Permissions
  • Even if we assign "Read" role on the lakehouse, if users are Members of the workspace, they can insert, update, delete, or alter lakehouse tables.
  • We want the curated team to be Members of their workspace (so they can build models, views, and manage sharing), but not able to change source data.
• No Way to Enforce Read-Only in Lakehouse
  • There is currently no mechanism to enforce read-only access to a lakehouse for workspace members.
  • Table-level properties cannot restrict DML operations.
  • So we cannot safely use the lakehouse for raw data without risk of accidental data corruption

Current Workaround (Not Ideal)

• We maintain ingestion pipelines in the ingestion workspace.
• We ingest data directly into a lakehouse in the curated workspace.
• We’ve added RLS to the SQL endpoint, and are instructing curated data developers to only use the SQL endpoint, where they can’t execute DML by default.
• However, this is not scalable or robust. There's still no way to enforce this policy at the platform level.

What We Need

• A way to truly enforce read-only access to lakehouses, regardless of workspace role.
• Ideally:
  • Shortcuts would allow us to delegate security only at the target lakehouse.
  • Or, Microsoft introduces lakehouse-level DML restrictions that override workspace membership.

Questions

• Is there a way to prevent data manipulation language operations in a lakehouse (INSERT, UPDATE, DELETE, ALTER) to members of a workspace (override priviledges granted to the workspace member role)?
• Is there now a way — or is there going to be a way — to delegate security of shortcutted tables to the target lakehouse, thereby removing the need to grant access to the source lakehouse?
• Does Microsoft Purview allow us the ability to override workspace membership and grant users read access and the ability to create views in a lakehouse without enabling full modification rights? (Note: We don’t manage M365, only Fabric, and currently don’t have access to Purview. Would this be an option for us if our M365 team enables it? Don't want to go down that path until I know it will do what we need it to.)

Thanks in advance for any insight.