topic Re: Lakehouse table security in Data Engineering

Lakehouse table security

schneiw — Fri, 13 Mar 2026 13:35:56 GMT

Hello Community!

For our internal IT team, we have general read access to all SQL Endpoints of Lakehouses (via workspace access setting) and also have the ReadAll setting applied on each Lakehouse as well, so that they can have read access via Notebooks.

One of our Lakehouses contains replicated tables from the ERP system. A requirement from Finance is that no one except a certain group has access to the GL tables. Is there away to set a "deny" on all the non authorized groups to specify that certain table(s) may not be accessed? I believe we can do this over the SQL Endpoint via grant statements in SQL, but how does one do this so that a notebook also cannot access the table(s) since it does not use the SQL Endpoint?

I have seen suggestions to have those tables in their own seperate Lakehouse - but that seems like some overkill, is there no easier method to block access to specific tables when accessing via Notebooks?

Thank you!

Re: Lakehouse table security

Srisakthi — Fri, 13 Mar 2026 15:09:31 GMT

Hi @schneiw ,

Have you tried One lake security(preview) feature

https://learn.microsoft.com/en-us/fabric/onelake/security/row-level-security

Regards,

Srisakthi

Re: Lakehouse table security

Olufemi7 — Tue, 17 Mar 2026 00:08:21 GMT

Hello @schneiw,

No. SQL GRANT/DENY only works on the SQL Endpoint; notebooks access Delta tables directly, so those permissions aren’t enforced.

To restrict access (for example GL tables), move them to a separate Lakehouse and grant access only to the authorized group.

Docs: https://learn.microsoft.com/fabric/data-engineering/lakehouse-overview

Re: Lakehouse table security

Lozovskyi — Tue, 17 Mar 2026 00:19:17 GMT

Hello @schneiw, there is no Deny as of today; however, you can do that by leveraging One lake security preview.

To simplify the solution and maintenance undertaking, you can store GL data under one schema.

Then define a role to read data inside this schema.

add allowed user group as a member and then share the lakehouse with this group. when sharing the lakehouse, keep all selections unticked. By that, users will see the lakehouse under the OneLake catalog.

If you need to grant them SQL endpoint access, go to the SQL endpoint and switch to Use OneLake security for tables (User's identity access mode)

It's important to keep in mind that having higher-level rights (shared read All, or having workspace-level access) will override this security setup.

Re: Lakehouse table security

v-echaithra — Fri, 20 Mar 2026 14:07:13 GMT

Hi @schneiw ,

Thank you @Lozovskyi , @Olufemi7 , @Srisakthi for your inputs.

We’d like to follow up regarding the recent concern. Kindly confirm whether the issue has been resolved, or if further assistance is still required. We are available to support you and are committed to helping you reach a resolution.

Thank you.