Unity Catalog attribute-based access control (ABAC)

Beta

This feature is in Beta.

This page describes attribute-based access control (ABAC) in Unity Catalog.

What is ABAC?

ABAC is a data governance model that provides flexible, scalable, and centralized access control across Databricks. ABAC complements Unity Catalog's existing privilege model by allowing policies to be defined based on governed tags, which are applied to data assets. This simplifies governance and strengthens security posture.

Users with MANAGE permissions or object ownership need only define policies once and can apply them consistently across many data assets. Policies are attached at the catalog, schema, or table level and automatically apply to all tables within that scope. When defined at higher levels, policies inherit downward to child objects. Governed tags on data assets determine which policies are enforced, allowing access control to adapt dynamically.

Benefits of ABAC

• Scalability: Manage access controls at scale by leveraging tags instead of individual permissions.
• Flexibility: Easily adjust governance by updating tags or policies without modifying each data asset.
• Centralized governance: Simplify policy management through a unified model that spans catalogs, schemas, and tables.
• Improved security: Enforce fine-grained access controls dynamically based on data attributes.
• Auditability: Maintain real-time visibility into data access through comprehensive audit logs.

How ABAC works

ABAC in Unity Catalog uses governed tags, policies, and user-defined functions (UDFs) to enforce dynamic, attribute-based access control. The following components and mechanisms are central to ABAC:

• Governed tags: Governed tags are defined at the account level using tag policies. These tags represent attributes such as data sensitivity, classification, or business domain, and are assigned to tables, schemas, or catalogs in Unity Catalog. They serve as the attributes that drive policy enforcement. See Tag policies and Apply tags to Unity Catalog securable objects.

• Policies: Policies are created and managed at three hierarchical levels within Unity Catalog:

  • Catalog level: Apply broad policies affecting all contained schemas and tables.
  • Schema level: Apply policies specific to a schema and its tables.
  • Table level: Apply fine-grained policies directly on individual tables.

  Policies follow an inheritance model: when a policy is defined at the catalog or schema level, it automatically applies to all child objects, schemas, and tables within that scope. This allows administrators to implement high-leverage governance by applying a single policy that governs large sets of data assets. Inherited policies reduce redundancy and promote consistent enforcement across the data hierarchy. Databricks recommends defining policies at the highest applicable level, usually the catalog, to maximize governance efficiency and reduce administrative overhead. See Create and manage attribute-based access control (ABAC) policies.

• User-defined functions (UDFs): UDFs are custom functions defined at the schema level and can be referenced globally across the Unity Catalog namespace. UDFs are used within policies to express complex logic, such as filtering rows or masking column values based on attributes. For example, a UDF named filter_region might be used in a row filter policy to only return rows where region = 'EMEA'. See User-defined functions (UDFs) in Unity Catalog.

• Dynamic enforcement: When a user attempts to access a tagged data asset, Unity Catalog evaluates the applicable policies based on the tags and enforces the defined access controls.

  Users who are explicitly excluded from a policy can continue perform actions such as deep and shallow cloning, and time travel on the underlying data.

• Audit logging: All operations on tagged data assets are captured and logged in the audit log system table, enabling comprehensive visibility and compliance tracking. See Audit logs.

To learn how to configure ABAC, see Tutorial: Configure ABAC.

Policy types

Two types of ABAC policies are supported:

• Row filter policies restrict access to individual rows in a table based on their content. A filter UDF evaluates whether each row should be visible to a user. These policies are useful when access depends on data characteristics.

  Example use case: Only show rows in a customer transactions table where the region column matches a governed tag such as region=EMEA. This allows regional teams to see only data relevant to their geography.

• Column mask policies control what values users see in specific columns. A masking UDF can return the actual value or a redacted version, based on governed tags.

  Example use case: Mask a column containing phone numbers unless the table is tagged sensitivity=low or the requesting user is in a compliance group. Users without access see a null or placeholder value like XXX-XXX-XXXX.

See Create and manage attribute-based access control (ABAC) policies.

Beta limitations

The following limitations apply during the ABAC preview stages:

• A user who has MODIFY permissions on a table but does not have ASSIGN tag policy permissions can drop a column that has a governed tag. This alters the table structure and might invalidate the ABAC policy tied to that column.
• The ABAC beta is enabled at the workspace level. Databricks does not enforce ABAC policies on catalogs when they are accessed from workspaces not enabled in the beta.
• Users with the required Delta Sharing permissions can Delta share tables secured by ABAC policies regardless of how the policy applies to them. The policy does not govern the recipient’s access.
• Views are not supported.
• Foreign catalogs are not supported.
• Only one column mask or row filter can be applied to a given column or row within the object hierarchy. Applying multiple masks or filters might make the table inaccessible.

• ABAC is not supported on Databricks on AWS GovCloud or workspaces with FedRAMP moderate compliance controls.