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`;