From fb8b39432c7d56f0b4918d49dfca915ba783f790 Mon Sep 17 00:00:00 2001 From: Andres Bolanos <93162854+a-bolanos@users.noreply.github.com> Date: Wed, 25 Mar 2026 17:05:33 -0400 Subject: [PATCH 1/3] Update materialized view policies documentation Clarified behavior of row level security policies on materialized views and source tables, including user access implications. --- .../management/materialized-views/materialized-view-policies.md | 1 + 1 file changed, 1 insertion(+) diff --git a/data-explorer/kusto/management/materialized-views/materialized-view-policies.md b/data-explorer/kusto/management/materialized-views/materialized-view-policies.md index 5fbef9df43..2b6297b43d 100644 --- a/data-explorer/kusto/management/materialized-views/materialized-view-policies.md +++ b/data-explorer/kusto/management/materialized-views/materialized-view-policies.md @@ -44,6 +44,7 @@ A [row level security](../row-level-security-policy.md) can be applied on a mate * The policy is applied to the [materialized part](materialized-view-overview.md#how-materialized-views-work) of the view only. * If the same row level security policy isn't defined on the source table of the materialized view, then querying the materialized view may return records that should be hidden by the policy. This happens because [querying the materialized view](materialized-view-overview.md#materialized-views-queries) queries the source table as well. * We recommend defining the same row level security policy both on the source table and the materialized view if the view is an [arg_max()](../../query/arg-max-aggregation-function.md) or [arg_min()](../../query/arg-min-aggregation-function.md)/[take_any()](../../query/take-any-aggregation-function.md). + * If a row level security policy is defined on the source table and a user is not included in the source table's policy, querying the materialized view fails even if the user is included in the materialized view's own row level security policy. This is because the [delta part](materialized-view-overview?view=microsoft-fabric#how-materialized-views-work) of the query accesses the source table directly, and the source table's row level security policy is enforced on that access. To resolve this, either add the user to the source table's row level security policy, or use the [materialized_view()](materialized-view-function?view=microsoft-fabric) function to query only the materialized part of the view, which does not require access to the source table. * When defining a row level security policy on the source table of an [arg_max()](../../query/arg-max-aggregation-function.md) or [arg_min()](../../query/arg-min-aggregation-function.md)/[take_any()](../../query/take-any-aggregation-function.md) materialized view, the command fails if there's no row level security policy defined on the materialized view itself. The purpose of the failure is to alert the user of a potential data leak, since the materialized view may expose information. To mitigate this error, do one of the following actions: * Define the row level security policy over the materialized view. * Choose to ignore the error by adding `allowMaterializedViewsWithoutRowLevelSecurity` property to the alter policy command. For example: From e5bf1859d5d33c6728448af5d7e475b74f5cd250 Mon Sep 17 00:00:00 2001 From: Andres Bolanos <93162854+a-bolanos@users.noreply.github.com> Date: Wed, 25 Mar 2026 17:15:30 -0400 Subject: [PATCH 2/3] Fix row level security policy description in documentation Fix relative link to materialized_view() function --- .../management/materialized-views/materialized-view-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/data-explorer/kusto/management/materialized-views/materialized-view-policies.md b/data-explorer/kusto/management/materialized-views/materialized-view-policies.md index 2b6297b43d..129aaad037 100644 --- a/data-explorer/kusto/management/materialized-views/materialized-view-policies.md +++ b/data-explorer/kusto/management/materialized-views/materialized-view-policies.md @@ -44,7 +44,7 @@ A [row level security](../row-level-security-policy.md) can be applied on a mate * The policy is applied to the [materialized part](materialized-view-overview.md#how-materialized-views-work) of the view only. * If the same row level security policy isn't defined on the source table of the materialized view, then querying the materialized view may return records that should be hidden by the policy. This happens because [querying the materialized view](materialized-view-overview.md#materialized-views-queries) queries the source table as well. * We recommend defining the same row level security policy both on the source table and the materialized view if the view is an [arg_max()](../../query/arg-max-aggregation-function.md) or [arg_min()](../../query/arg-min-aggregation-function.md)/[take_any()](../../query/take-any-aggregation-function.md). - * If a row level security policy is defined on the source table and a user is not included in the source table's policy, querying the materialized view fails even if the user is included in the materialized view's own row level security policy. This is because the [delta part](materialized-view-overview?view=microsoft-fabric#how-materialized-views-work) of the query accesses the source table directly, and the source table's row level security policy is enforced on that access. To resolve this, either add the user to the source table's row level security policy, or use the [materialized_view()](materialized-view-function?view=microsoft-fabric) function to query only the materialized part of the view, which does not require access to the source table. + * If a row level security policy is defined on the source table and a user is not included in the source table's policy, querying the materialized view fails even if the user is included in the materialized view's own row level security policy. This is because the [delta part](materialized-view-overview.md#how-materialized-views-work) of the query accesses the source table directly, and the source table's row level security policy is enforced on that access. To resolve this, either add the user to the source table's row level security policy, or use the [materialized_view()](../../query/materialized-view-function) function to query only the materialized part of the view, which does not require access to the source table. * When defining a row level security policy on the source table of an [arg_max()](../../query/arg-max-aggregation-function.md) or [arg_min()](../../query/arg-min-aggregation-function.md)/[take_any()](../../query/take-any-aggregation-function.md) materialized view, the command fails if there's no row level security policy defined on the materialized view itself. The purpose of the failure is to alert the user of a potential data leak, since the materialized view may expose information. To mitigate this error, do one of the following actions: * Define the row level security policy over the materialized view. * Choose to ignore the error by adding `allowMaterializedViewsWithoutRowLevelSecurity` property to the alter policy command. For example: From f931c68edc4c020324773718cb0d2b557873d5aa Mon Sep 17 00:00:00 2001 From: Andres Bolanos <93162854+a-bolanos@users.noreply.github.com> Date: Wed, 25 Mar 2026 17:24:42 -0400 Subject: [PATCH 3/3] Update row level security policy details for materialized views Clarified the implications of row level security policies on querying materialized views, including conditions for failure and resolution options. --- .../materialized-views/materialized-view-policies.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/data-explorer/kusto/management/materialized-views/materialized-view-policies.md b/data-explorer/kusto/management/materialized-views/materialized-view-policies.md index 129aaad037..ab06d3a8e7 100644 --- a/data-explorer/kusto/management/materialized-views/materialized-view-policies.md +++ b/data-explorer/kusto/management/materialized-views/materialized-view-policies.md @@ -44,7 +44,9 @@ A [row level security](../row-level-security-policy.md) can be applied on a mate * The policy is applied to the [materialized part](materialized-view-overview.md#how-materialized-views-work) of the view only. * If the same row level security policy isn't defined on the source table of the materialized view, then querying the materialized view may return records that should be hidden by the policy. This happens because [querying the materialized view](materialized-view-overview.md#materialized-views-queries) queries the source table as well. * We recommend defining the same row level security policy both on the source table and the materialized view if the view is an [arg_max()](../../query/arg-max-aggregation-function.md) or [arg_min()](../../query/arg-min-aggregation-function.md)/[take_any()](../../query/take-any-aggregation-function.md). - * If a row level security policy is defined on the source table and a user is not included in the source table's policy, querying the materialized view fails even if the user is included in the materialized view's own row level security policy. This is because the [delta part](materialized-view-overview.md#how-materialized-views-work) of the query accesses the source table directly, and the source table's row level security policy is enforced on that access. To resolve this, either add the user to the source table's row level security policy, or use the [materialized_view()](../../query/materialized-view-function) function to query only the materialized part of the view, which does not require access to the source table. + * If the source table has a row level security policy and a user isn't included in it, querying the materialized view fails. This happens even if the user is included in the materialized view's own row level security policy. The failure occurs because the [delta part](materialized-view-overview.md#how-materialized-views-work) of the query accesses the source table directly, where the source table's row level security policy is enforced. To resolve this issue, use one of the following options: + * Add the user to the source table's row level security policy. + * Use the [materialized_view()](../../query/materialized-view-function.md) function to query only the materialized part of the view. This function doesn't require access to the source table. * When defining a row level security policy on the source table of an [arg_max()](../../query/arg-max-aggregation-function.md) or [arg_min()](../../query/arg-min-aggregation-function.md)/[take_any()](../../query/take-any-aggregation-function.md) materialized view, the command fails if there's no row level security policy defined on the materialized view itself. The purpose of the failure is to alert the user of a potential data leak, since the materialized view may expose information. To mitigate this error, do one of the following actions: * Define the row level security policy over the materialized view. * Choose to ignore the error by adding `allowMaterializedViewsWithoutRowLevelSecurity` property to the alter policy command. For example: