Securing Unity Catalog: Who Gets What
Grant privileges, implement table and column-level access control, and configure row-level security β the core of Unity Catalog's security model.
How Unity Catalog security works
Unity Catalog security works like a building with security badges.
Every person (user), robot (service principal), or team (group) gets a badge. The badge determines which floors (catalogs), rooms (schemas), and file cabinets (tables) they can access.
Permissions flow downward β if you have access to a floor, you can enter every room on that floor unless a specific room is locked. This is called privilege inheritance.
For extra sensitive data, you can lock individual drawers (columns) or show different drawer contents to different people (row-level security).
Principals: who can access data
| Principal Type | What It Is | Example |
|---|---|---|
| User | Individual human identity (synced from Microsoft Entra ID) | ravi.nair@datapulse.com |
| Service principal | Application identity for automated access | sp-etl-pipeline |
| Group | Collection of users and/or service principals | data-engineers, bi-analysts |
Best practice: Always grant permissions to groups, not individual users. When Mei Lin onboards a new analyst at Freshmart, she adds them to the bi-analysts group β they instantly inherit all the right permissions.
Privilege hierarchy
Privileges flow down the Unity Catalog namespace:
Metastore
βββ Catalog (GRANT on catalog β inherits to all schemas/tables below)
βββ Schema (GRANT on schema β inherits to all tables below)
βββ Table / View / Volume / Function
Common privileges
| Privilege | What It Allows | Securable Objects |
|---|---|---|
| SELECT | Read data | Table, View |
| MODIFY | Insert, update, delete data | Table |
| CREATE TABLE | Create tables within a schema | Schema |
| CREATE SCHEMA | Create schemas within a catalog | Catalog |
| USE CATALOG | Access objects in the catalog | Catalog |
| USE SCHEMA | Access objects in the schema | Schema |
| ALL PRIVILEGES | Full access | Any securable |
| EXECUTE | Run a function | Function |
-- Grant a group permission to read all tables in a schema
GRANT USE CATALOG ON CATALOG prod_sales TO `bi-analysts`;
GRANT USE SCHEMA ON SCHEMA prod_sales.reports TO `bi-analysts`;
GRANT SELECT ON SCHEMA prod_sales.reports TO `bi-analysts`;
-- Grant a service principal full access to raw data
GRANT ALL PRIVILEGES ON SCHEMA prod_sales.raw TO `sp-etl-pipeline`;
-- Revoke access
REVOKE SELECT ON TABLE prod_sales.curated.customer_pii FROM `bi-analysts`;
Exam tip: USE CATALOG + USE SCHEMA are required
A common exam trap: granting SELECT on a table is not enough. The principal also needs:
- USE CATALOG on the parent catalog
- USE SCHEMA on the parent schema
- SELECT on the table
Without all three, the query fails with a βcatalog not foundβ or βschema not foundβ error. The exam tests this with scenarios where a user has SELECT but canβt see the table.
Table and column-level access control
Column-level access
Restrict which columns specific users can see:
-- Analyst group can see orders but NOT customer_email or credit_card
GRANT SELECT (order_id, order_date, amount, region)
ON TABLE prod_sales.curated.orders
TO `bi-analysts`;
When a BI analyst queries the table, they only see the four granted columns. Attempting to SELECT customer_email returns an access denied error.
Row-level security
Row-level security filters rows based on whoβs querying. Dr. Sarah Okafor uses this at Athena Group so each regional manager only sees their own regionβs data:
-- Create a row filter function
CREATE FUNCTION prod_sales.functions.region_filter(region_col STRING)
RETURN IF(
IS_ACCOUNT_GROUP_MEMBER('global-admins'),
TRUE, -- admins see everything
region_col = CURRENT_USER_ATTRIBUTE('region') -- others see only their region
);
-- Apply the row filter to a table
ALTER TABLE prod_sales.curated.daily_revenue
SET ROW FILTER prod_sales.functions.region_filter ON (region);
Now when a user in the APAC group queries daily_revenue, they only see APAC rows. Global admins see all rows.
Compute access permissions
Compute resources also have access controls:
| Permission | What It Allows |
|---|---|
| CAN ATTACH TO | Use the cluster to run notebooks |
| CAN RESTART | Restart the cluster |
| CAN MANAGE | Full control (configure, start, stop, delete) |
Dr. Sarah Okafor grants:
- data-engineers group β CAN MANAGE on dev clusters
- bi-analysts group β CAN ATTACH TO on shared SQL warehouse
- sp-etl-pipeline β CAN ATTACH TO on job clusters
Exam tip: Compute permissions are separate from data permissions. A user needs BOTH compute access (to run queries) AND data access (to read tables).
π¬ Video coming soon
Knowledge check
A BI analyst at Freshmart reports they can't find the 'prod_sales' catalog when running queries. Mei Lin checks and confirms the analyst has SELECT on the table they need. What is the most likely cause?
Dr. Sarah Okafor needs to ensure that each regional sales manager at Athena Group can only see data from their own region when querying the daily_revenue table. Global admins should see all regions. Which approach should she use?
Next up: Secrets & Authentication β Azure Key Vault integration, service principals, and managed identities.