Forum Discussion
Restricted View Policy Bug
Hi haku99,
Thank you for the follow-up question.That sounds like a practical approach given your organization’s preference for SAS authentication. I’m glad the explanation helped you make an informed decision.
If you ever decide to explore Managed Identity in the future, it can offer smoother integration with Fabric’s security layers, but your current setup should work just fine without the restricted view policy. Really appreciate you taking the time to share your outcome it’ll surely help others facing a similar situation.
Wishing you all the best with your Event house setup, and don’t hesitate to reach out again if any new questions come up.
Thank you for being part of the Microsoft Fabric Community Forum.
Hello
This is as expected. The database does not support any security functions to a streaming enabled table.
From the documentation we get this paragraph:
Limitations
- There's no limit on the number of tables on which Row Level Security policy can be configured.
- Row Level Security policy cannot be configured on External Tables.
- The RLS policy can't be enabled on a table under the following circumstances:
- When it's referenced by an update policy query, while the update policy is not configured with a managed identity.
- When it's referenced by a continuous export that uses an authentication method other than impersonation.
- When a restricted view access policy is configured for the table.
- The RLS query can't reference other tables that have Row Level Security policy enabled.
- The RLS query can't reference tables located in other databases.
Row level security policy - Kusto | Microsoft LearnTo come around this, you need to remove the securty function on the table and, if needed for RLS or other purposes, create a medallion architecture, as I try to show in this blogpost:
Worlds Fastest Medallion Load
Appreciate your response datacoffee .
I agree there were limitations but was trying to see if this is a known limitation or is it something thats Microsoft not aware. My goal of using restricted policy in this scenario is, I am dumping all the data from event hub in this table and transferring the data to other tables after transformations using update policies. I dont want the users to access this data dump table and I am exploring ways to achieve this.
Got it!
then I would look into a database split of data for ingestion and data for consumption. Then you can define the access on table level and database level on the consumption based database and keep the streaming data in the ingestion database
there are a lot of options to come around this, the split database option is the easy fix here 😊
Thats a great idea datacoffee. But update policies dont work cross database I presume. And I have a constraint of not deduping data and maintatining real time latency. What would be a optimal way to achieve that?
A materialized view is doable across databases.
Even though you have the requirement to add a SUMMARIZE function to the view, you can always do that across all columns and do the agreegation on a dummy column.
It sounds "hacky" but it works like a charm