07.6 Unity Catalog Permissions, RBAC & Privilege Inheritance
Unity Catalog security is easiest to understand as five connected concepts:
Identity → Privilege → Securable Object → Inheritance → Workspace Boundary
A sixth layer handles fine-grained data policy:
ABAC / row filters / column masks / governed views
This chapter builds the enterprise authorization model from first principles and then turns it into practical SQL, troubleshooting steps, and architect-level design patterns.
1. The Unity Catalog authorization problem
An enterprise lakehouse has:
- analysts
- data engineers
- BI tools
- ETL service principals
- ML workloads
- data stewards
- platform administrators
- application identities
Granting permissions individually to every table does not scale.
Unity Catalog provides a hierarchical object model:
Metastore | +-- Catalog | +-- Schema | +-- Table / View +-- Volume +-- Function / Model
The objective is to place a grant at the lowest practical business boundary and allow inheritance to do the repetitive work.
2. Five dimensions of access
| Dimension | Question |
|---|---|
| Identity | Who is making the request? |
| Privilege | What operation is allowed? |
| Object | Which securable object is protected? |
| Inheritance | Did the grant come from a parent? |
| Boundary | Is the object available from this workspace? |
Then ask a sixth question:
| Dimension | Question |
|---|---|
| Data policy | Is access further restricted by ABAC, row filters, masks, or views? |
This is why a SELECT failure should not automatically lead to another SELECT grant.
3. Principals
Unity Catalog privileges can be granted to:
- users
- groups
- service principals
Recommended enterprise pattern
Human user ↓ Identity provider ↓ Account group ↓ Unity Catalog grants
Prefer:
finance_readers finance_engineers finance_data_stewards production_writers finance_etl_sp
over:
User A → SELECT User B → SELECT User C → SELECT
Groups provide centralized onboarding, offboarding, auditing, and reusable roles.
4. Account-level identity design
A single Unity Catalog metastore can serve multiple workspaces.
Unity Catalog Metastore | +-----+-----+ | | | DEV TEST PROD | | | WS-A WS-B WS-C
Use account-level groups for enterprise roles whenever possible.
Typical groups:
- data-platform-admins
- data-engineers
- finance-analysts
- finance-data-stewards
- bi-readers
- production-writers
Workspace-specific groups are useful only when the boundary is genuinely workspace-specific.
5. Securable object hierarchy
Unity Catalog securable objects are hierarchical.
METASTORE | +-- CATALOG | +-- SCHEMA | +-- TABLE +-- VIEW +-- VOLUME +-- FUNCTION
The familiar three-level namespace is:
catalog.schema.object
Example:
enterprise_finance.controlling.cost_center_actuals
Catalogs and schemas are container objects. This is what makes inherited permissions possible.
6. Privilege inheritance
A privilege granted on a parent can apply to current and future child objects.
CATALOG ↓ SCHEMA ↓ TABLE / VIEW / VOLUME / FUNCTION
Example:
GRANT SELECT ON SCHEMA enterprise_finance.controlling TO finance_readers;
This is generally preferable to granting SELECT individually to every table in the schema.
A catalog-level grant is broader:
GRANT SELECT ON CATALOG enterprise_finance TO finance_readers;
Use broad catalog grants deliberately because they can cover a large future object population.
7. Metastore-level privileges are different
Do not confuse:
metastore governance privileges
with:
data access privileges
Metastore-level grants control metastore-scoped operations such as creating catalogs or managing certain storage objects.
They generally do not mean:
"The user can read every table."
The exception worth remembering is READ METADATA, which has special inheritance behavior in the Unity Catalog permissions model.
8. Ownership
Every securable object has an owner.
The owner has powerful capabilities over that object, including privilege administration and ownership transfer.
The object creator is commonly the initial owner.
Production recommendation
Do not leave important production objects owned by individual developers.
Use group ownership:
Developer creates object ↓ Production data-owner group ↓ Long-term governance
Example:
ALTER TABLE enterprise_finance.controlling.cost_center_actuals OWNER TO finance-data-stewards;
Ownership is not the same as ordinary ALL PRIVILEGES and should be treated as a governance responsibility.
9. Ownership does not simply cascade
A critical rule:
Ownership does not inherit downward.
Owning a catalog does not mean the same principal becomes the owner of every table.
However, ownership provides management capabilities over child objects according to the Unity Catalog permission model.
Therefore distinguish:
Object ownership ≠ Child-object ownership
This matters when designing stewardship and separation of duties.
10. MANAGE vs ownership
This is one of the most important Unity Catalog security distinctions.
Ownership
The owner has all capabilities on the owned object according to the ownership model.
MANAGE
MANAGE allows a principal to administer privileges, transfer ownership, and delete an object where permitted.
But:
MANAGE does not automatically grant every data privilege.
A principal with MANAGE may explicitly grant itself data privileges such as SELECT when appropriate.
Think of it as:
OWNER └── broad capabilities on owned object
MANAGE └── administrative control
SELECT / MODIFY / READ VOLUME └── data-operation privileges
This separation is useful for separation of duties.
11. USE CATALOG and USE SCHEMA
A common mistake is:
"The group has SELECT, therefore it can query the table."
The complete access path often requires:
USE CATALOG + USE SCHEMA + SELECT ↓ Table read
Example:
GRANT USE CATALOG ON CATALOG enterprise_finance TO finance_readers;
GRANT USE SCHEMA ON SCHEMA enterprise_finance.controlling TO finance_readers;
GRANT SELECT ON SCHEMA enterprise_finance.controlling TO finance_readers;
USE privileges establish the path through the hierarchy. They do not themselves grant SELECT or MODIFY.
12. Common privilege families
| Privilege | Typical purpose |
|---|---|
| USE CATALOG | Access the catalog namespace |
| USE SCHEMA | Access the schema namespace |
| SELECT | Read table/view data |
| MODIFY | Change table data |
| CREATE TABLE | Create tables in a container |
| CREATE VIEW | Create views |
| READ VOLUME | Read files in a volume |
| WRITE VOLUME | Write files in a volume |
| MANAGE | Administer grants/ownership |
| BROWSE | Discover metadata without granting data access |
Always consult the current privilege reference for object-specific requirements.
13. CREATE privileges
Creation privileges should be granted at the container where creation is allowed.
Example:
GRANT CREATE TABLE ON SCHEMA enterprise_finance.controlling TO finance_engineers;
A common engineering access model is:
USE CATALOG + USE SCHEMA + CREATE TABLE
Production write access should be evaluated separately.
14. SELECT vs MODIFY
Treat read and write permissions as different security classes.
SELECT
Allows reading data.
MODIFY
Allows changing table data.
A good production rule is:
Keep analytics read access broad enough for the business, but keep production MODIFY access narrow.
For example:
BI users → SELECT
Finance engineers → CREATE + controlled MODIFY
ETL service principal → required production MODIFY
Data steward → governance administration
Avoid giving analysts production MODIFY merely because they need to query data.
15. Service principals
Production automation should normally use machine identities.
Examples:
- sp-finance-etl
- sp-sap-cdc
- sp-salesforce-ingestion
- sp-bi-refresh
- sp-ml-pipeline
Avoid:
Employee identity ↓ Production ETL
Prefer:
Job ↓ Service principal ↓ Unity Catalog grants ↓ Production data
Benefits:
- stable identity
- better auditability
- safe employee offboarding
- separation of duties
- least privilege
16. Workspace bindings are another boundary
Privileges are not the only access control.
A catalog can be bound to specific workspaces and can be configured for read-only access from selected workspaces.
Example:
PROD CATALOG | +---+----------------+ | | PROD workspace BI workspace read/write read-only
This creates defense in depth:
Identity + Privilege + Workspace binding
Effective access boundary
An explicit SELECT grant does not override a workspace binding that prevents the workspace from accessing the catalog.
17. Catalog-level vs schema-level grants
Use the narrowest practical container.
Catalog level
Good for:
- broad domain access
- enterprise-wide readers
- platform teams
- common governance capabilities
Risk:
- broad inheritance
- larger blast radius
Schema level
Good for:
- subject areas
- teams
- finance/controlling/procurement domains
- environment boundaries
Table level
Good for:
- sensitive exceptions
- unusual datasets
- special access requirements
Architectural rule:
Prefer container-level grants when the business boundary is hierarchical. Use table-level grants for exceptions.
18. SAP/BW enterprise mapping
A useful SAP-oriented design could be:
sap_prod | +-- fi +-- co +-- mm +-- sd +-- pp
Possible role model:
SAP Finance readers → sap_prod.fi → SELECT
SAP Controlling readers → sap_prod.co → SELECT
SAP Data Engineers → required engineering schemas → CREATE / controlled MODIFY
SAP ingestion service principal → required target schemas → MODIFY
BI service principal → Gold schemas → SELECT
This maps technical access to recognizable business domains.
19. SHOW GRANTS: primary troubleshooting tool
When access fails, inspect the actual grants.
Catalog:
SHOW GRANTS ON CATALOG enterprise_finance;
Schema:
SHOW GRANTS ON SCHEMA enterprise_finance.controlling;
Table:
SHOW GRANTS ON TABLE enterprise_finance.controlling.cost_center_actuals;
You can also inspect grants for a specific principal.
The objective is to determine:
- Which principal is actually executing?
- Which groups does it belong to?
- Which grants exist?
- Where were the grants applied?
- Which grants are inherited?
- Is the current workspace allowed to access the object?
20. Eight-step access troubleshooting
When a user says:
"I have SELECT but cannot query the table."
Do this in order.
Step 1 — Identity
Confirm the user or service principal.
Step 2 — Group membership
Confirm the expected account-group membership.
Step 3 — Catalog
Check USE CATALOG.
Step 4 — Schema
Check USE SCHEMA.
Step 5 — Object
Check SELECT, MODIFY, READ VOLUME, or the operation actually required.
Step 6 — Inheritance
Determine whether the grant came from catalog, schema, or object.
Step 7 — Workspace
Check catalog/workspace binding.
Step 8 — Fine-grained policy
Check ABAC, row filters, column masks, or views where applicable.
Do not fix authorization problems by blindly adding more privileges.
21. Common failure patterns
Failure 1 — SELECT without usage privileges
The principal has SELECT but cannot traverse the parent namespace.
Failure 2 — Correct grant, wrong workspace
The catalog is not available from the workspace.
Failure 3 — Direct user grants everywhere
This creates permission sprawl.
Failure 4 — Developer owns production data
Offboarding and operational ownership become risky.
Failure 5 — MANAGE mistaken for SELECT
Administrative control does not automatically equal data access.
Failure 6 — Broad catalog-level grants
A group gets access to much more data than required.
Failure 7 — Analysts receive production MODIFY
Read-oriented consumers receive unnecessary write capability.
22. RBAC design pattern
For a finance domain:
finance-data-stewards | ownership / MANAGE | +------+------+ | | finance finance engineers readers | | CREATE + SELECT controlled MODIFY | +------ finance ETL service principal | MODIFY
This separates:
- governance
- engineering
- consumption
- automation
23. RBAC vs ABAC vs row and column controls
These mechanisms solve different problems.
| Mechanism | Best suited for |
|---|---|
| RBAC / privileges | Who can access an object |
| Workspace bindings | Where an object can be accessed |
| ABAC | Centralized tag/attribute-driven policies |
| Row filters | Which rows are visible |
| Column masks | Which values are visible |
| Views | Curated access interfaces |
A mature architecture combines them.
Identity ↓ RBAC / grants ↓ Workspace boundary ↓ ABAC ↓ Row / column controls ↓ Data
Do not force every security requirement into table grants.
24. Hands-on Lab 1 — Read-only analyst role
Create:
catalog: demo_governance schema: sales group: sales_readers
Grant:
GRANT USE CATALOG ON CATALOG demo_governance TO sales_readers;
GRANT USE SCHEMA ON SCHEMA demo_governance.sales TO sales_readers;
GRANT SELECT ON SCHEMA demo_governance.sales TO sales_readers;
Verify:
SHOW GRANTS ON SCHEMA demo_governance.sales;
Create another table in the schema and test whether the inherited access behaves as expected.
Goal: understand explicit versus inherited grants.
25. Hands-on Lab 2 — Engineer role
Create:
sales_engineers
Grant:
GRANT USE CATALOG ON CATALOG demo_governance TO sales_engineers;
GRANT USE SCHEMA ON SCHEMA demo_governance.sales TO sales_engineers;
GRANT CREATE TABLE ON SCHEMA demo_governance.sales TO sales_engineers;
Then decide whether production MODIFY should belong to:
- engineers
- a service principal
- both
Document the security reasoning.
26. Hands-on Lab 3 — Deliberate permission failure
Give a test principal SELECT but omit the appropriate usage privileges.
Attempt to query the table.
Then troubleshoot using:
Identity ↓ Group ↓ USE CATALOG ↓ USE SCHEMA ↓ Object privilege ↓ Inheritance ↓ Workspace binding ↓ Fine-grained policy
The goal is to learn diagnosis instead of permission escalation.
27. Hands-on Lab 4 — Production service principal
Design:
sales_etl_sp
It should:
- read required source data
- write only required target tables
- not own the entire catalog
- not receive unnecessary administrative privileges
Document:
- catalogs
- schemas
- read privileges
- write privileges
- ownership
- MANAGE requirements
- workspace restrictions
This is an architect-level exercise.
28. Architect decision framework
Before granting a permission, ask:
- Is this a human or machine identity?
- Should access be group-based?
- What is the smallest securable object representing the business boundary?
- Can the privilege be inherited from a schema?
- Does the principal need data access or administrative control?
- Does the workspace need access to the catalog?
- Is the requirement actually row-level or column-level?
- Can a service principal replace human production write access?
- Who owns the object?
- How will this access be audited six months from now?
29. Enterprise RBAC blueprint
ACCOUNT | +-- Identity provider | | | +-- Users | +-- Groups | +-- Service principals | +-- Unity Catalog Metastore | +-- Domain Catalogs | +-- Subject Schemas | +-- Tables +-- Views +-- Volumes | +-- Group grants +-- Service-principal grants +-- Ownership +-- MANAGE delegation | +-- Workspace bindings | +-- Audit / lineage / governance
This is the enterprise mental model to use before designing individual grants.
30. Production checklist
- Users are managed through enterprise identity management.
- Access is primarily group-based.
- Service principals exist for production automation.
- Production objects are not owned by individual developers.
- Catalog/schema boundaries match business domains.
- USE CATALOG and USE SCHEMA are intentional.
- Broad catalog grants have been reviewed.
- Production MODIFY is restricted.
- MANAGE is assigned sparingly.
- Workspace bindings are intentional.
- Fine-grained controls are used where required.
- SHOW GRANTS can explain access decisions.
- Access is documented by role.
- Offboarding removes group membership rather than requiring table-by-table cleanup.
- Service-principal permissions are periodically reviewed.
31. Interview questions
Q1. What is privilege inheritance?
A privilege granted on a parent container can automatically apply to child securable objects, including current and future objects.
Q2. Does ownership inherit?
No. Ownership does not simply cascade to child objects.
Q3. MANAGE vs ownership?
Ownership provides broad capabilities on the owned object. MANAGE delegates administrative control but does not automatically grant all data privileges.
Q4. Is SELECT always sufficient?
No. Appropriate parent usage privileges can also be required.
Q5. Why use groups?
Groups make authorization scalable, auditable, and easier to operate.
Q6. Why use service principals?
They provide stable non-human identities for production workloads.
Q7. Can SELECT override workspace restrictions?
No. Workspace bindings are an additional boundary.
Q8. Should analysts receive production MODIFY?
Generally no. Keep production writes tightly controlled.
Q9. What does SHOW GRANTS provide?
It helps inspect the grants on securable objects and troubleshoot authorization.
Q10. Should ALL PRIVILEGES be the default?
No. Use least privilege and grant only what the workload requires.
32. Final mental model
Remember:
WHO? ↓ User / Group / Service Principal
WHAT? ↓ Privilege
WHERE? ↓ Catalog / Schema / Table / Volume / Function
HOW DOES IT FLOW? ↓ Privilege inheritance
WHERE CAN IT RUN? ↓ Workspace binding
WHO ADMINISTERS IT? ↓ Owner / MANAGE
IS DATA STILL RESTRICTED? ↓ ABAC / row filters / masks / views
The architect objective is not simply to give access.
It is to give exactly the required access, at the correct boundary, with predictable inheritance and auditable ownership.