Access Control in Unity Catalog

Privilege Model

Unity Catalog uses a role-based privilege model. Each privilege grants specific capabilities on a securable object.

Core Privileges

OWNER — Full control over an object, including ability to grant/revoke permissions, modify, and delete. Only one owner per object.
USE CATALOG — Allows browsing and listing contents of a catalog. Required to access any schema or table within.
USE SCHEMA — Allows browsing and listing tables within a schema. Required to access tables.
SELECT — Read-only access to table data. Can query but not modify.
MODIFY — Can insert, update, delete, or truncate table data. Requires SELECT.
CREATE — Can create new objects (tables, views, functions) within a schema or catalog.
ALL PRIVILEGES — Grants all available privileges on an object (equivalent to OWNER for most objects).

Securable Objects

Objects that can have permissions assigned in Unity Catalog:

Catalogs — Top-level containers
Schemas — Logical groupings within catalogs
Tables — Structured data objects
Views — Virtual tables (follow same permissions as tables)
Functions — User-defined functions (UDFs) and SQL functions
Volumes — External storage containers for unstructured data
Models — Machine learning models stored in MLflow

Privilege Inheritance Hierarchy

Permissions flow top-down through the namespace hierarchy:

Metastore
  └── Catalog
        └── Schema
              └── Table / View / Function / Volume / Model

If a user has SELECT on a schema, they inherit SELECT on all tables in that schema (unless explicitly restricted). To access a table, users must have sufficient privileges at all parent levels (USE CATALOG, USE SCHEMA, SELECT).

Identity Management

Permissions are granted to identities, which include:

Users — Individual user accounts (email addresses)
Groups — Collections of users for easier bulk permission management
Service Principals — Non-human identities for applications, jobs, and automation

Granting Permissions

-- Grant a single privilege to a user or group
GRANT SELECT ON TABLE finance_prod.transactions.orders TO `analyst@company.com`;

-- Grant multiple privileges
GRANT SELECT, MODIFY ON TABLE finance_prod.transactions.orders TO `data-engineer@company.com`;

-- Grant at schema level (affects all tables in schema)
GRANT USE SCHEMA ON SCHEMA finance_prod.transactions TO `analytics-team@company.com`;
GRANT SELECT ON SCHEMA finance_prod.transactions TO `analytics-team@company.com`;

-- Grant at catalog level (affects all schemas and tables)
GRANT USE CATALOG ON CATALOG finance_prod TO `all-employees@company.com`;

-- Grant to a service principal
GRANT SELECT ON TABLE finance_prod.transactions.orders
  TO `my-app-service-principal@example.com`;

Revoking Permissions

-- Revoke a specific privilege
REVOKE SELECT ON TABLE finance_prod.transactions.orders FROM `analyst@company.com`;

-- Revoke all privileges
REVOKE ALL PRIVILEGES ON TABLE finance_prod.transactions.orders FROM `analyst@company.com`;

-- Revoke at schema or catalog level
REVOKE USE SCHEMA ON SCHEMA finance_prod.transactions FROM `old-team@company.com`;

Viewing Permissions

-- View all principals with access to an object
SHOW GRANTS ON TABLE finance_prod.transactions.orders;

-- View all grants for a specific principal (what can they access?)
SHOW GRANTS TO `analyst@company.com`;

-- View grants on a schema
SHOW GRANTS ON SCHEMA finance_prod.transactions;

-- View grants on a catalog
SHOW GRANTS ON CATALOG finance_prod;

Best Practices

Principle of Least Privilege

Grant only the minimum permissions needed. Start restrictive (no access) and add permissions as required rather than starting permissive and removing later.

Analysts need SELECT, not MODIFY
Engineers need MODIFY only on dev/staging, not prod
Service principals for read-only processes should have SELECT only

Use Groups, Not Individual Users

Always grant permissions to groups rather than individual email addresses:

-- Good: grant to a group
GRANT SELECT ON CATALOG finance_prod TO `finance-analysts@company.com`;

-- Bad: grant to individuals (hard to manage at scale)
GRANT SELECT ON CATALOG finance_prod TO `alice@company.com`;
GRANT SELECT ON CATALOG finance_prod TO `bob@company.com`;
GRANT SELECT ON CATALOG finance_prod TO `charlie@company.com`;

Separate Environments

Create separate catalogs for dev, staging, and production. Grant different groups access to each:

-- Dev: full access for engineers
GRANT ALL PRIVILEGES ON CATALOG finance_dev TO `data-engineers@company.com`;

-- Staging: limited for testing
GRANT SELECT, MODIFY ON CATALOG finance_staging TO `data-engineers@company.com`;

-- Prod: restricted access, read-only for most
GRANT SELECT ON CATALOG finance_prod TO `analytics-team@company.com`;
GRANT MODIFY ON CATALOG finance_prod TO `dba-team@company.com`;

Audit and Review Regularly

Periodically review who has access to sensitive data:

-- Audit all permissions across a catalog
SHOW GRANTS ON CATALOG finance_prod;

-- Identify over-permissioned users
SHOW GRANTS TO `contractor-account@company.com`;

Use Dynamic Permissions Sparingly

If using row-level or column-level security, consider masking PII and restricting sensitive attributes at the table level first, then apply fine-grained controls as needed.

Common Permission Patterns

Read-Only Analytics

GRANT USE CATALOG ON CATALOG finance_prod TO `analytics-team@company.com`;
GRANT USE SCHEMA ON SCHEMA finance_prod.transactions TO `analytics-team@company.com`;
GRANT SELECT ON SCHEMA finance_prod.transactions TO `analytics-team@company.com`;

Data Engineering in Dev/Staging

GRANT ALL PRIVILEGES ON CATALOG finance_dev TO `data-engineers@company.com`;
GRANT ALL PRIVILEGES ON SCHEMA finance_dev.etl TO `data-engineers@company.com`;

Production Read-Only with Change Control

-- Analysts: read only
GRANT USE CATALOG ON CATALOG finance_prod TO `analytics-team@company.com`;
GRANT SELECT ON CATALOG finance_prod TO `analytics-team@company.com`;

-- DBAs: manage schema (with approval process outside UC)
GRANT MODIFY ON CATALOG finance_prod TO `dba-team@company.com`;