Skip to main content
Last updated on

Requirements, quotas, and limitations for row filter and column mask policies

note

This page covers requirements, quotas, and limitations for row filter and column mask policies. For GRANT policies, see ABAC GRANT policies.

This page lists requirements, policy quotas, and current limitations for ABAC row filter and column mask policies in Unity Catalog.

Compute requirements​

To use ABAC policies, you must use one of the following compute configurations:

For guidance on running workloads that require older runtimes, see Access from older runtimes.

Governed tags requirement​

ABAC policies use governed tags, not ungoverned tags. Governed tags are defined at the account level with access controls that determine who can create, assign, and manage them. For full details, see Governed tags.

note

After assigning or modifying a tag, it can take a few minutes for the change to take effect.

Policy quotas​

Resource

Limit

Policies per metastore (all objects)

10,000

Policies per metastore, attached directly (Beta)

100

Policies per catalog

100

Policies per schema

100

Policies per table

50

Principals per policy (applies to TO and EXCEPT clauses)

20

Column conditions per MATCH COLUMNS clause

3

Resource

Limit

Policies per metastore (all objects)

10,000

Policies per metastore, attached directly (Beta)

100

Policies per catalog

100

Policies per schema

100

Policies per table

50

Principals per policy (applies to TO and EXCEPT clauses)

20

Column conditions per MATCH COLUMNS clause

3

For more details, including governed tags quotas, see Service limits.

ABAC limitations​

Identity attributes in policy conditions​

The has_identity_attribute_value and has_identity_attribute_tag_match functions evaluate the identity attributes of the user running the query. They are supported in the WHEN clause of column mask policies. The following limitations apply:

  • They are not supported in the MATCH COLUMNS clause of column mask policies.
  • They are not supported in GRANT or DENY policies.
  • The policy creation interface in Catalog Explorer does not support attribute functions. Use SQL to create these policies.

For usage patterns, see Mask a column based on attributes of the querying user.

Access from older runtimes​

Standard and dedicated compute on Databricks Runtime versions earlier than 16.4 can't access ABAC-secured tables. If you need certain workloads to continue running on an older runtime, scope the ABAC policy to a specific group instead of applying it broadly. Add only the users or principals you want the policy to apply to that group, and exclude the principal that runs the older-runtime workload using the EXCEPT clause. Users outside the group retain full access to the underlying tables. This allows that workload to continue accessing the tables while you transition to a supported runtime.

ABAC policies on views​

Beta

Applying ABAC policies to views is in Beta. To use it, an account admin must enable the ABAC on Views preview from the account console Previews page, and you must use Databricks Runtime 19 or above. See Manage account-level previews.

The following requirements and limitations apply to policies on views:

  • Metric views are not supported: You can't apply ABAC policies to metric views.
  • A single query can layer at most 20 policies: A base table can have a policy, and each view built on top of it can have its own policy. When a query reads through a view, all applicable policies apply, at each level of the hierarchy. If more than 20 policies would apply, the query fails.
  • CREATE OR REPLACE VIEW drops governed tags and directly attached policies: Replacing a view with a CREATE OR REPLACE statement clears the view's metadata, along with its governed tags and any directly attached policies. To preserve metadata, use ALTER VIEW instead. If you do use CREATE OR REPLACE, reapply the governed tags and policies afterward.
  • Columns with governed tags cannot be dropped until the tags are removed: As with base tables, governed tags must be removed from a view's column before dropping it. Otherwise, policies that depend on the tag could drop inadvertently.

ABAC policies on materialized views and streaming tables​

When a pipeline refreshes a materialized view or streaming table, it evaluates policies using the pipeline owner's or run-as identity. If that identity is subject to an ABAC policy, the materialized view or streaming table permanently contains masked or filtered data. To avoid this, add the pipeline owner or run-as identity to the EXCEPT clause of ABAC policies associated with all the tables being read during the pipeline refresh. Use the TO clause to specify which users and groups receive masked or filtered data.

OpenSharing tables with ABAC policies or views that reference them​

Tables with ABAC policies or views that reference tables with ABAC policies can only be shared through OpenSharing if the share owner is exempt from the policy (listed in the EXCEPT clause). The policy doesn't govern the recipient's access. Recipients can apply their own ABAC policies to shared tables to enforce access control on their side.

For details on how to use OpenSharing with ABAC, see OpenSharing and ABAC.

Time travel and cloning on tables with ABAC policies​

ABAC policies can't be evaluated against historical table snapshots, so time travel queries fail on tables with active row filters or column masks. Deep and shallow clones also aren't supported on tables with ABAC policies.

To enable these operations, create a service principal or group and add it to the policy's EXCEPT clause. The policy isn't evaluated for exempted principals, so these operations can run.

important

Exempted principals see unfiltered, unmasked data. Only exempt trusted identities such as service principals used for ETL or pipeline workloads.

For example, the following policy masks PII columns for all users except the etl_service_principal, which can run time travel queries and clone operations:

SQL
CREATE POLICY mask_pii
ON CATALOG prod
COLUMN MASK prod.governance.mask_value
TO `account users`
EXCEPT `etl_service_principal`
FOR TABLES
MATCH COLUMNS
  has_tag_value('pii', 'ssn') AS ssn
ON COLUMN ssn;

AI Search indexes and ABAC policies​

ABAC policies on a source table don't apply to AI Search indexes created from that table. The index syncs all rows from the source table and doesn't enforce row filter or column mask policies when serving queries.

For tables with column masks, you can exclude masked columns from the index using the columns to sync setting.

Multiple policies on the same table or column for the same user​

Only one distinct row filter can resolve at runtime for a given table and a given user, and only one distinct column mask can resolve for a given column and a given user. You can define multiple policies, but when a user queries the table, only one policy's conditions must match. If multiple distinct row filters or column masks apply to the same user and table or column, Databricks blocks access and returns an error. Multiple policies are allowed if they resolve to the same row filter or column mask UDF with the same arguments.

For details, see Conflicting filters and masks.

ABAC on dedicated compute​

For limitations of ABAC on dedicated compute, see Limitations.

Limitations common to ABAC and table-level row filters and column masks​

For general limitations of row filters and column masks that apply to both ABAC and table-level row filters and column masks, see Limitations.

On this page