Access control in Unity Catalog

This page has an overview of access control in Unity Catalog, including privileges, policies, and data-level controls.

Layers of access control

Access control in Unity Catalog is built on the following complementary models:

• Workspace-level restrictions control where users can access data, by limiting objects to specific workspaces.
• Privileges and ownership control who can access what, using grants on securable objects.
• Attribute-based policies (ABAC) control what data users can access, using governed tags and centralized policies.
• Table-level filtering and masking control what data users can see within tables using table-specific filters and views.

These models work together to enforce secure, fine-grained access across your data environment.

Layer	Purpose	Mechanisms
Workspace-level restrictions	Limit which workspaces can access specific catalogs, external locations, and storage credentials	Workspace-level bindings
Privileges and ownership	Control access to catalogs, schemas, tables, and other objects	Privilege grants to users and groups, object ownership
Attribute-based policies	Use tags and policies to dynamically apply filters and masks	ABAC policies and governed tags
Table-level filtering and masking	Control what data users can see within tables	Row filters, column masks, dynamic views

Workspace-level restrictions

Workspace binding limits which workspaces in your account can access specific catalogs, external locations, and storage credentials. This access control happens at the workspace level and applies regardless of user or group privileges.

By default, all catalogs, external locations, and storage credentials in Unity Catalog are accessible from any workspace attached to the same metastore. Using bindings you can:

• Restrict access to one or more designated workspaces
• Make catalog access read-only from certain workspaces
• Isolate environments, for example, restrict production data to production workspaces
• Limit use of external locations and storage credentials to specific workspaces

These bindings override user-level permissions. If a user has privileges on an object but tries to access it from an unbound workspace, access is denied.

For more information, see Limit catalog access to specific workspaces.

Privileges and ownership

Access in Unity Catalog is primarily governed by privileges and object ownership. This model defines who can access or manage data and metadata by assigning admin roles and by granting privileges and managing ownership across securable objects. This section describes how privileges are granted, how ownership works, and which admin roles can manage access across different scopes.

Admin roles

Unity Catalog supports multiple admin roles:

• Account admin: Can create metastores, manage identities, assign metastore admins, and manage account-level features like Delta Sharing and system tables.
• Metastore admin: An optional but powerful role that can manage all objects in the metastore, transfer ownership, and assign top-level privileges like CREATE CATALOG, CREATE EXTERNAL LOCATION, and more.
• Workspace admin: Manages identities, workspace-level settings, and the workspace catalog.

For details, see Admin privileges in Unity Catalog.

Object ownership

Every securable object, such as a catalog, schema, or table, in Unity Catalog has an owner. Ownership grants full control over that object, including the ability to:

• Read or modify the object and its metadata
• Grant privileges to other users
• Transfer ownership to another principal

Unity Catalog also supports a MANAGE privilege, which allows users to grant access and modify objects without making them the owner.

For more on ownership, see Manage Unity Catalog object ownership.

Privileges on securable objects

In Unity Catalog, access control starts with privileges. You assign privileges such as SELECT, MODIFY, and USE SCHEMA to users and groups on securable objects such as catalogs, schemas, tables, views, volumes, and functions.

Privilege enforcement is:

• Hierarchical: Grants on higher-level objects, like catalogs, cascade to lower-level objects, like tables.
• Delegable: Every object has an owner who can manage it and grant access to others.
• Explicit: Access is only allowed when a user or group has been granted the appropriate privileges. A user is granted the union of permissions from all the groups they are a member of.

For more information, see Manage privileges in Unity Catalog and Unity Catalog privileges and securable objects.

Attribute-based access control (ABAC)

Beta

This feature is in Beta.

ABAC is a centralized, tag-based policy framework for enforcing access control in Unity Catalog. It enables admins to define scalable policies that apply dynamically across catalogs, schemas, and tables based on governed tags. Policies can filter data or mask sensitive values. Databricks recommends using ABAC for centralized and scalable governance, rather than applying filters or masks individually on each table.

ABAC is designed as a general-purpose framework for applying access control policies based on metadata attributes. It complements privilege-based controls and supports fine-grained enforcement without requiring per-object configuration.

Key features:

• Tag-driven policies: Define policies once using governed tags and user-defined functions (UDFs), and apply them consistently across many data assets.
• Hierarchical enforcement: Apply policies at the catalog, schema, or table level with automatic inheritance to child objects.
• Centralized, scalable governance: Manage access at scale without assigning individual privileges on each object.
• Dynamic evaluation: Access decisions are evaluated in real time based on tags and user context.

For more information, see Unity Catalog attribute-based access control (ABAC).

Table-level filtering and masking

This section covers mechanisms that control what data users can see at query time using table-specific logic. These include:

• Row filters and column masks: apply logic directly to tables.
• Dynamic views: define logic using SQL over one or more tables.

These approaches can be used independently or alongside ABAC, depending on your governance model.

Row filters and column masks

Row filters and column masks apply filter or mask logic directly to individual tables using UDFs. They are useful when you want to enforce logic per table without centralized policy management.

For more, see Row filters and column masks.

Dynamic views

Dynamic views allow you to define logic over one or more tables using SQL. They are read-only and useful for:

• Applying transformation logic (for example joins and CASE statements)
• Sharing filtered data using Delta Sharing, where ABAC is not supported.

For details, see Create a dynamic view.

When to use each access control mechanism

Workspace bindings, privileges, and ABAC policies all evaluate access at different levels, and they are designed to be used together. The following table compares them across common access control criteria:

note

Databricks recommends using ABAC to centralize and scale access control based on governed tags. Use row filters and column masks only when you need per-table logic or haven't adopted ABAC yet.

Mechanism	Applies to	Defined using	Use case
Workspace bindings	Catalogs, external locations, storage credentials	Workspace assignment	Restricting access to objects from specific workspaces
Privileges	Catalogs, schemas, tables	Grants (GRANT, REVOKE), ownership	Baseline access and delegation
ABAC policies	Tagged objects (tables, schemas)	Policies with governed tags and UDFs	Centralized, tag-driven policies and dynamic enforcement
Table-level row/column filters	Individual tables	UDFs on the table itself	Table-specific filtering or masking
Dynamic views	Views over one or more tables	SQL (with embedded filters or masks)	Read-only access, complex logic, Delta Sharing