Unity Catalog Security

Unity Catalog (UC) is the policy plane for every securable on a Databricks lakehouse — catalogs, schemas, tables, columns, volumes, models, external locations, storage credentials, and Delta Sharing shares. This page ties together the UC privilege model, the securable hierarchy, external-location wiring, attribute-based access control with tags, and the privilege matrix you reach for when granting access.

1. Securable Hierarchy

Every privilege in UC is granted on one of these securables. Privileges flow downward by inheritance — a grant on a catalog applies to every schema and table beneath it unless explicitly revoked at a lower level.

2. Three-Level Namespace

UC tables are addressed as catalog.schema.table. This replaces the two-level database.table from the legacy Hive metastore.

-- Read with full three-level name
SELECT * FROM finance_prod.tx.payments;

-- Set a default catalog/schema for the session
USE CATALOG finance_prod;
USE SCHEMA tx;
SELECT * FROM payments;

3. Privilege Matrix

The privileges below are the most common across UC securables. USE CATALOG and USE SCHEMA are traversal privileges — without them the user cannot reach the inner securables even if they have SELECT on the table itself.

Privilege	Catalog	Schema	Table / View	Function	Volume
USE CATALOG	List schemas	—	—	—	—
USE SCHEMA	—	List objects	—	—	—
SELECT	(via inheritance)	(via inheritance)	Read rows	—	Read files
MODIFY	(via inheritance)	(via inheritance)	INSERT / UPDATE / DELETE	—	Write files
CREATE	CREATE SCHEMA	CREATE TABLE / VIEW / FUNCTION / VOLUME	—	—	—
EXECUTE	—	—	—	Invoke UDF	—
READ VOLUME	—	—	—	—	List + read paths
WRITE VOLUME	—	—	—	—	Upload / overwrite
ALL PRIVILEGES	All of the above on this catalog and below	All on schema and below	All on object	All on UDF	All on volume

4. Owner Privileges

Every securable has exactly one owner (a user, group, or service principal). The owner can:

Grant and revoke any privilege on the securable.
Drop or rename the securable.
Transfer ownership to another principal.

-- Make a group the owner (recommended over individual users)
ALTER TABLE finance_prod.tx.payments OWNER TO `data-platform-owners@company.com`;

-- See the current owner
DESCRIBE EXTENDED finance_prod.tx.payments;

Owning a catalog or schema does not automatically grant SELECT on its tables — owners can grant themselves SELECT but it must be explicit. This is the same defensive design as Snowflake's OWNERSHIP.

5. External Locations & Storage Credentials

UC decouples which cloud bucket from who can access it:

Storage Credential — an IAM role (AWS), managed identity (Azure), or service account (GCP) registered in UC. The credential defines what can be done at the cloud-IAM level.
External Location — a (storage credential, path-prefix) pair. Grants READ FILES / WRITE FILES / CREATE EXTERNAL TABLE on a specific path.

-- 1. Register the IAM role
CREATE STORAGE CREDENTIAL finance_role
  WITH (AWS_ROLE_ARN = 'arn:aws:iam::123:role/dbx-finance');

-- 2. Define the external location
CREATE EXTERNAL LOCATION finance_raw
  URL 's3://acme-finance-raw/'
  WITH (CREDENTIAL finance_role);

-- 3. Grant access
GRANT READ FILES ON EXTERNAL LOCATION finance_raw
  TO `finance-engineers@company.com`;
GRANT CREATE EXTERNAL TABLE ON EXTERNAL LOCATION finance_raw
  TO `finance-engineers@company.com`;

Without an external location, no compute in the workspace can read raw paths in that bucket — even if the underlying IAM role grants s3:GetObject. UC enforces the path boundary on top of cloud IAM.

6. Attribute-Based Access Control (Tags)

Tags are key/value pairs attached to any securable. Governed tags (Public Preview) constrain which values are allowed and integrate with policy expressions, enabling attribute-based access control (ABAC) — grants that apply to any object carrying a particular tag.

-- Tag a column as PII
ALTER TABLE finance_prod.tx.payments
  ALTER COLUMN ssn SET TAGS ('classification' = 'pii_high');

-- Tag a whole schema
ALTER SCHEMA finance_prod.pii
  SET TAGS ('domain' = 'finance', 'sensitivity' = 'restricted');

-- Discover all PII columns across the metastore
SELECT *
FROM   system.information_schema.column_tags
WHERE  tag_name = 'classification' AND tag_value = 'pii_high';

Common tagging patterns:

classification = public | internal | confidential | pii_high
domain = finance | marketing | hr
retention = 30d | 1y | 7y
data_owner = finance-data-owners@company.com

Pair tags with row-filter UDFs that call is_account_group_member() to build policies like "users see PII columns only if they're in the privacy team and the column is tagged pii_high."

7. Best Practices

Grant on groups, never on individual emails.
One catalog per environment (dev / stage / prod) — easier to lock prod down to read-only.
Make a group the owner of every catalog/schema, not a single human.
Use external locations as the boundary for raw bucket access; never grant ANY FILE at the catalog level.
Tag every PII / restricted column at ingest time; use tags to drive masks and lineage queries.
Audit grants via system.access.audit (see Audit Logs & Compliance).
Combine with row filters and column masks for fine-grained controls within the table.