Writing ABAC Row Filter and Column Mask Policies

1.Permissions and compute requirements

Two privileges are needed to create an ABAC policy, one on the attachment point and one on the logic. You "must have MANAGE on the securable object where the policy is attached (catalog, schema, or table) or own the securable object, and EXECUTE" on the UDF that implements the filter or mask. Attaching a policy at the metastore level requires a metastore admin. Looking at policies needs less: "Viewing policies (show, describe) requires READ METADATA or MANAGE on the securable object, or object ownership." The environment also has to support the policy. Databricks requires "Databricks Runtime 16.4 or above, or serverless compute." The target objects must already carry governed tags. You can create a policy from the Policies tab in Catalog Explorer, with the CREATE POLICY statement, or with the REST APIs, SDKs and Terraform.

Sources1

2.Row filter policies

A row filter policy references a UDF that returns a boolean for each row. "Rows where the function returns FALSE are excluded from query results." The policy does not name the column the UDF reads. Instead, MATCH COLUMNS finds the column by its tag, and USING COLUMNS passes it to the function.

CREATE FUNCTION filter_by_region(region STRING, allowed STRING) RETURNS BOOLEAN
    RETURN region = allowed;

CREATE POLICY regional_access_emea
ON CATALOG sales
ROW FILTER filter_by_region
TO `emea team`
FOR TABLES
MATCH COLUMNS has_tag('region') AS rgn
USING COLUMNS (rgn, 'EMEA');

Passing constants is what lets you reuse one UDF: another policy could call filter_by_region with 'APAC'. Constants can be quoted strings, numeric literals, booleans or NULL. Write the UDF in SQL where you can. "SQL UDFs are recommended for better performance." Python UDFs registered in Unity Catalog also work, but the optimizer cannot inline them. One trap is specific to row filters. If the rgn alias matches more than one column in a table, the engine does not know which value to pass.

Sources2

3.Column mask policies

A column mask policy references a UDF that takes the column value and returns either that value or a masked version. The difference from a row filter is the ON COLUMN clause. "The masked column value is bound automatically as the first argument from the ON COLUMN clause". USING COLUMNS therefore carries only the extra arguments. In the example below, the constant 4 tells the function how many trailing digits to reveal.

CREATE FUNCTION mask_ssn(ssn STRING, show_last INT) RETURNS STRING
    RETURN CONCAT('***-**-', RIGHT(ssn, show_last));

CREATE POLICY mask_ssn_columns
ON CATALOG hr_catalog
COLUMN MASK mask_ssn
TO `account users` EXCEPT `compliance team`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'ssn') AS ssn_col
ON COLUMN ssn_col
USING COLUMNS (4);

Two rules matter here. First, "The return type must match or be castable to the column's data type." Second, a masked column cannot feed another policy: "If a column is masked by one policy, it cannot be used as an input argument in the USING COLUMNS clause of another policy." This rule stops a row filter from reading a value that is supposed to be hidden.

CREATE POLICY mask_ssn
ON SCHEMA prod.customers
COLUMN MASK ssn_to_last_nr
TO us_analysts EXCEPT admins
FOR TABLES
MATCH COLUMNS  ? ('pii', 'ssn') AS ssn
ON COLUMN ssn
USING COLUMNS (4);

Sources23

4.Enforcement at query time: fail-closed, dependencies and conflicts

Policies are evaluated each time a query runs, for the user who runs it. "Different users may see different results from the same query because policy evaluation depends on the user's identity, group memberships, and the tags" on the data. Unity Catalog finds every policy whose scope covers the table. It checks whether the user is in TO and not in EXCEPT, then evaluates the table and column conditions. The runtime then enforces the result as a secure view over the table scan. This is the same mechanism that table-level filters and masks use.

"ABAC follows a fail-closed model, where Databricks defaults to denying access if it cannot verify security." So the query on 15.4 is denied; it neither returns raw data nor quietly masks it. The same rule covers operations that cannot enforce filters or masks. Examples include deep and shallow cloning, OpenSharing and AI Search index syncing. "To run them, the principal must be listed in the EXCEPT clause of every ABAC policy that applies to the table."

Policies also fail closed when something they depend on is removed. If you delete a governed tag that a policy references, every query in that policy's scope fails with UC_ABAC_UNKNOWN_TAG_POLICY. "This occurs even if the tag was not applied to the queried tables." If you delete a referenced UDF, queries fail with UC_DEPENDENCY_DOES_NOT_EXIST. Databricks also refuses to drop a column that carries a governed tag. This affects pipelines that change their schema.

Conflicts follow the same rule as on the previous page: one distinct row filter per table and one distinct mask per column, for each user. Overlap is allowed when it is harmless. "Multiple ABAC policies can coexist for the same table or column if they result in the same effective filter or mask." When the effective filters or masks differ, access is blocked with an error such as UC_ABAC_MULTIPLE_ROW_FILTERS. To diagnose it, "Use SHOW EFFECTIVE POLICIES to see all policies that apply to the table."

Sources3

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.The column being masked must be listed first in USING COLUMNS so the UDF receives it.Why is that wrong?

   The masked column is bound automatically from ON COLUMN as the UDF's first argument. USING COLUMNS supplies only the additional arguments.

   Covered in Column mask policies

2. 2.Deleting a governed tag only affects tables that actually carry that tag.Why is that wrong?

   If a policy references the deleted tag, every query in the policy's scope fails, including queries on tables that never had the tag.

   Covered in Enforcement at query time: fail-closed, dependencies and conflicts

3. 3.Compute that cannot enforce ABAC, such as a runtime older than 16.4, simply returns the unfiltered data.Why is that wrong?

   ABAC fails closed: access is denied unless the user is exempted from the policy through EXCEPT.

   Covered in Enforcement at query time: fail-closed, dependencies and conflicts

Practise it for real

Protect SSN columns across a whole schema with one tag-driven column mask policy, then confirm which policies apply to a table.

1. 1.Run CREATE GOVERNED TAG pii with DESCRIPTION and VALUES ('ssn', 'ccn', 'dob'), as in the governed tag example.

   Why: Policies match on governed tags, and allowed values stop stewards from inventing variants such as 'SSN'.

   You should see: The pii tag appears under Govern > Governed Tags, marked with a lock icon.

2. 2.In Catalog Explorer, apply pii = ssn directly to the SSN column of a table in your target schema.

   Why: Column tags are never inherited, so each sensitive column must be tagged itself.

   You should see: The column shows the governed pii tag with the value ssn.

3. 3.Create the ssn_to_last_nr function and the mask_ssn policy ON SCHEMA from the policy example, replacing us_analysts and admins with your own groups.

   Why: One schema-level policy covers every current and future table whose columns carry pii = ssn.

   You should see: The policy appears on the schema's Policies tab.

4. 4.Run SHOW EFFECTIVE POLICIES against the tagged table, then query it as a member of the TO group and as a member of the EXCEPT group.

   Why: Policies are evaluated per user, so the same query should return different results for the two users.

   You should see: The policy is listed. The TO user sees only the last 4 characters of the SSN, and the exempt user sees the full value.