Skip to content

SYSTEM Cited by 2 sources

Unity Catalog ABAC (Attribute-Based Access Control)

Unity Catalog ABAC policies are Unity Catalog's dynamic access-control model — a single policy evaluates tag-based conditions on Unity Catalog objects and applies row filters (which rows a user sees) and column masks (what values a user sees for specific columns) automatically to every matching object across entire catalogs and schemas. Reached General Availability on 2026-05-13 alongside Governed Tags and Data Classification.

What it replaces

The architectural shift is from per-object configuration (every table that needs a row filter or column mask gets its own configuration) to declarative policy evaluation against governed-tag attributes. Per-object configuration is "repetitive and prone to inconsistency": "different masking logic for the same column type, outdated rules on older tables, conflicting definitions across teams" (Source: sources/2026-05-13-databricks-abac-row-filtering-and-column-masking-policies-governed-tags). A single ABAC policy referencing the pii:ssn tag covers every column across every table in every catalog tagged accordingly — and starts covering new columns the moment the tag is applied (whether by a human steward or by automated classification).

Core operating shape

SQL query  ──▶  query planner
                   │
                   ▼
       ┌───────────────────────────────┐
       │  ABAC policy evaluation       │
       │                               │
       │  for each object referenced:  │
       │    look up object's governed  │
       │    tags + inherited tags from │
       │    parent catalog/schema      │
       │                               │
       │    match policies whose       │
       │    tag-condition predicate    │
       │    holds for current_user()   │
       │                               │
       │    apply row filter           │
       │    + column mask UDF          │
       └───────────────────────────────┘
                   │
                   ▼
           rewritten plan with filters / masks
                   │
                   ▼
           execution engine returns redacted result

GA-disclosed properties

Enterprise-scale policy limits

GA grew policy limits 10× across every scope:

  • 10,000+ policies per metastore
  • 100+ per catalog
  • 100+ per schema

(Source: sources/2026-05-13-databricks-abac-row-filtering-and-column-masking-policies-governed-tags; "Policy limits grew 10x across every scope, with support for 10,000+ policies per metastore and 100+ per catalog and schema.") The 100+ per-catalog ceiling is what makes the design plausible for metastores with thousands of catalogs each carrying their own per-tenant or per-domain policy sets.

Session identity evaluation

ABAC at GA evaluates against the identity of the user running the query rather than the view creator's identity. "Users see exactly what their own permissions allow them to see, even when they query through a view or function." (Source: same.)

This is the load-bearing fix for the "view-as-bypass" failure mode: without session-identity, a per-user mask inside a view defined as SELECT mask(ssn) FROM customers would resolve current_user() to the view creator when the view is queried, defeating the per-user rule. See concepts/session-identity-evaluation for the full evaluation shape.

Single VARIANT UDF for many column types

A masking UDF accepting and returning VARIANT can mask INT, DOUBLE, DECIMAL, and other numeric types at once — and the same approach extends to STRUCT columns. The architectural lever is type-erasure via a dynamically-typed wrapper: one UDF replaces N type-specific masking UDFs, "cuts down on the number of policies organizations need to maintain." Canonical instance of patterns/single-variant-udf-for-multi-type-masking.

Tag-driven evaluation

ABAC policies do not name tables — they name tag conditions. A policy fragment of the form "if a column carries pii:email, mask its value for users not in role compliance-reviewer" applies to every column carrying that tag in scope, including columns added or tagged after the policy was authored. New data picks up protection "as soon as the right tags are in place" (Source: same).

This is the load-bearing composition with systems/unity-catalog-governed-tags (the tag substrate) and systems/unity-catalog-data-classification (the auto-tagger). One policy + one classifier + one tag taxonomy = continuous coverage of new data.

What's not disclosed

  • Evaluation cost: per-query overhead for matching against 10K+ policies is not quantified.
  • Caching strategy: whether evaluated policy bindings per (object × user) are cached in the planner, and the invalidation semantics on tag changes.
  • Pre-GA limits: what the per-scope ceilings were before the GA 10× lift.
  • Policy-language schema: the post does not show ABAC policy SQL syntax in detail.
  • Conflict resolution: when multiple ABAC policies match a column (e.g., one tag-based mask and one role-based mask on the same column), the merge / precedence semantics.
  • Audit emission: whether ABAC evaluation produces an audit record per evaluation.
  • Interaction with prior ROW FILTER / MASK clauses: how legacy per-table row-filter / column-mask configurations coexist with ABAC policies on the same table.

Seen in

  • sources/2026-05-28-databricks-advancing-apache-iceberg-on-databricks-iceberg-v3-ga-open-sharing-and-unified-governance — Cross-engine ABAC reaches Beta, extending UC ABAC beyond the Databricks-compute boundary to any Iceberg client implementing the Iceberg REST Catalog Scan Planning API (Iceberg 1.11). Verbatim mechanism: "Administrators define policies once in UC, including column masks, row filters, and tag-based policies. When an external Iceberg engine requests access, UC evaluates the applicable policies during server-side scan planning. UC then returns a filtered scan plan so the engine only reads authorized data when processing the query." Compatible engines named: Apache Spark, DuckDB. Architecturally significant because it moves UC ABAC from a first-party-compute-only policy engine to a cross-engine policy engine — the same policies authored once cover queries from any conforming Iceberg engine. See concepts/cross-engine-abac + patterns/scan-planning-as-policy-enforcement-point. Beta release; no quantitative numbers; mechanism depth limited to the "server-side scan planning returns a filtered scan plan" shape.

  • sources/2026-05-13-databricks-abac-row-filtering-and-column-masking-policies-governed-tags — GA announcement with the 10× policy-limit growth, session identity evaluation, single VARIANT UDF for multi-type masking. Customer testimonials: Atlassian (Gerald Nakhle: "ABAC in Unity Catalog has allowed us to define fine-grained access policies based on data attributes, significantly reducing the operational overhead of managing permissions at scale") and Udemy (Rajit Saha: "Fewer policies, lower costs, surgical precision. ABAC transformed Udemy's data governance from brute-force to elegance.").

Last updated · 542 distilled / 1,571 read