Warehouse security when using Direct Lake models

[wardy912]

Hi Everyone,

 I have a warehouse that contains 2 schemas, support and finance.
I've built 2 Direct Lake models using the OneLake connector.

I am using item level permissions to ensure security.

It's my understanding that the users can only view the reports if they have 'read' and 'readall' item level permissions on the warehouse.

I'm trying to add granular permissions in T-SQL to prevent one group of users from accessing the finance schema, but it seems that the required item level permission 'readall' negates the rules I've added.

If a user gets access to a fabric capacity and creates a lakehouse, they can create a shortcut to the data that should be restricted.

Has anyone faced this issue and managed to resolve it? Is my only option creating separate warehouses?

[wardy912 · Accepted solution]

I have received information from the OneLake security team stating that they are actively working on a warehouse solution. In the meantime, I'll need to create a separate warehouse for each schema to ensure security.

[v-shchada-msft]

Hi @wardy912,

Thank you for reaching out to the Microsoft Fabric Community Forum, and thanks to the @tayloramy  for sharing helpful insights.

Just checking in, were you able to resolve the issue using any of the suggestions provided? If not, please feel free to share an update, and we'll be happy to assist further.

Your feedback will also help others facing similar challenges.
Thank you!

[wardy912]

Thanks @tayloramy ,

 That makes sense, it's too late to go back to SQL endpoint now.
ReadAll seems to be essential to use onelake connection.

[tayloramy]

Hi @wardy912, 

Yeah, security on warehouses leaves something to be desired for sure. 

For this reason I tend to use Lakehouses for all my stuff, then you can use OneLake Security and everything is fairly consistent.  

[tayloramy]

Hi @wardy912, 

You shouldn't need to grant readall if you have granted grnaular item level security on the tables in your warehouse. 

Note that if the permissions are applied on the TSQL level, then you will need to use DirectLake on SQL, not DirectLake on OneLake.