Amit_Dass_Chmp
Databricks Partner

1) Unity Catalog Is Account‑Level, Not Workspace‑Level

In legacy Databricks:

  • Entitlements (cluster creation, SQL access, workspace access) were workspace‑scoped
  • Often implicit or auto‑assigned
  • Loosely governed

In Unity Catalog:

  • Governance is account‑centric
  • Security policies must be consistent across workspaces
  • Nothing is assumed by default

Databricks documentation explicitly states that Unity Catalog unifies governance at the account level, decoupling it from individual workspaces

 

2) Unity Catalog Follows a Deny‑by‑Default Security Model

Legacy workspaces were:

  • Permissive by default
  • Access was often granted unless explicitly denied

Unity Catalog is:

  • Non‑permissive
  • Requires explicit grants
  • Designed for regulated, enterprise environments

Databricks describes this shift as moving from legacy access models to explicit, centralized governance.

Automatically migrating entitlements would violate the least‑privilege principle

What solution we have to migrate entitlements (rights it has) or in Hindi (Addhikar) :

Solution : Group‑Based Entitlement Re‑Assignment (Recommended)

What this means (conceptually)

Instead of assigning entitlements directly to Service Principals:

  • Create account‑level groups (e.g. sp-cluster-creators, sp-sql-users)
  • Add Service Principals to those groups
  • Assign entitlements to the group, not individuals

Why this is the best solution

  • Scales cleanly
  • Auditable
  • UC‑aligned
  • Prevents privilege drift
  • Matches enterprise IAM thinking

Unity Catalog principle satisfied

“Define once, govern everywhere.”

This is the preferred Databricks architecture for identity governance.

Hope you this answers! Thank you