Role-Level Policy Behavior in Databricks Unity Catalog¶

This guide explains how Privacera policies are enforced in Databricks Unity Catalog (UC) and how this differs from Snowflake’s role-switching model.

Key differences from Snowflake¶

• No role switching:
  • Unlike Snowflake, Databricks Unity Catalog doesn't have the concept of "primary" or "secondary" roles, nor does it use a SET ROLE command. There is no active role selection when a user logs in.
• A user’s effective permissions are the union of:
  • Direct grants to the user
  • Grants to all groups the user belongs to
  • Grants to any service principals associated with the user (if applicable), For details, see the Databricks documentation Databricks Docs
• No explicit DENY:
  • The UC privilege model is allow-based. It doesn't support explicit DENY statements. Instead, denials of access are typically modeled using row filters or column masking via dynamic views.

For UC privilege model, see the Databricks docs: Manage privileges in Unity Catalog.

How Privacera Policies Map to UC grants¶

Privacera evaluates "allow" policies and translates them directly into Databricks Unity Catalog grants on relevant securable objects, such as catalogs, schemas, and tables. If a user is in more than one group, the user gets all the permissions from those groups added together.

Example: Snowflake vs. Unity Catalog¶

• User XYZ belongs to groups Role_A, Role_B, and Role_C in Privacera.
• Policies:
  • Policy_A (Role_A): Grant SELECT on tables E, F
  • Policy_B (Role_B): Grant SELECT on tables G, H
  • Policy_C (Role_C): Grant SELECT on tables I, J

Behavior¶

Comments