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

┌──────────────────────────────────────────────────────────────────────────────────┐
│  UNITY CATALOG SECURABLE HIERARCHY                                               │
│                                                                                  │
│  Metastore                  (account-level, one per region)                      │
│  └── Catalog                (top-level namespace; e.g. finance_prod)             │
│       ├── Schema            (logical group; e.g. tx, pii, raw)                   │
│       │    ├── Table        (managed or external Delta)                          │
│       │    │    └── Column  (column-level masks + tags)                          │
│       │    ├── View         (virtual; honors base-table policies)                │
│       │    ├── Function     (SQL UDF; row filters / column masks)                │
│       │    ├── Volume       (unstructured-file container)                        │
│       │    └── Model        (MLflow registered model)                            │
│       └── External Location (storage path + storage credential)                  │
│                                                                                  │
│  Storage Credential         (IAM role / managed identity, account-level)         │
│  Connection                 (foreign catalog: Snowflake, Postgres, etc.)         │
│  Share                      (Delta Sharing recipient grants)                     │
└──────────────────────────────────────────────────────────────────────────────────┘

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:

-- 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:

-- 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:

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

↑ Back to Top

© Kevin Thomas Luzbetak, MSc