MilaFR's avatar
MilaFR
New Member
16 hours ago
Status:
New

Managing Purview Access in a OneLake Security-Enabled Fabric Environment

As OneLake Security is now enabled by default for supported Lakehouse items, Purview scanning appears to work differently for Lakehouses created before and after this change.

We are therefore looking for a centralized solution for managing Purview access across Fabric Lakehouses.

Assigning the Contributor role to the Purview Service Principal, as recommended, is unfortunately not an option for us due to our security and governance requirements.

We are looking for a solution that follows the principle of least privilege while minimizing operational overhead. Ideally, Purview should be able to access all relevant Lakehouses without requiring manual role assignments for each existing and newly created Lakehouse.

Could the Product Group please advise whether a centralized approach is planned, for example:

  • A tenant- or Fabric-level Default Reader, that can be assigned once and automatically applies to all Lakehouses.
  • Automatic inheritance of OneLake Security permissions for new Lakehouses;
  • Or another centrally managed mechanism that avoids per-Lakehouse configuration while maintaining read-only access?
  • Disable OneLake Security for specific Fabric 
No CommentsBe the first to comment

Recent ideas