Skip to main content

How are user permissions and access controls managed?

Summary

  • Databricks manages user permissions through Unity Catalog, a single authorization engine that governs data and AI objects with role-based access control (RBAC) using GRANT and REVOKE on a deny-by-default model.
  • Privileges inherit down the hierarchy: a grant on a catalog or schema applies to current and future child objects, and reading a table requires the full USE CATALOGUSE SCHEMASELECT chain.
  • Attribute-based access control (ABAC) lets you write one tag-based policy — for example, mask anything tagged as PII — that applies across catalogs and schemas without configuring each table.
  • Row filters and column masks enforce fine-grained security at query time, so they cannot be bypassed with a SELECT *.
  • Identities and groups sync from your identity provider through SSO and SCIM, and because Unity Catalog enforces at the SQL-engine level, the same permissions apply across SQL, notebooks, jobs, BI tools, and AI such as Genie and Agent Bricks.

How are user permissions and access controls managed?

Managing permissions means defining who can see and do what, keeping those rules consistent no matter how data is queried, and adjusting them as your organization grows. The Databricks Platform centralizes this in Unity Catalog, the single authorization engine for data and AI. Access is deny-by-default, permissions are granted with standard SQL and inherit down the object hierarchy, sensitive rows and columns can be protected at query time, and identities come from your existing identity provider — one governance model for analytics, applications, and AI.

Why the Databricks Platform manages permissions with Unity Catalog

  • Central RBAC with GRANT and REVOKE. Unity Catalog controls access through explicit privileges on securable objects, and nothing is accessible unless it is granted. Core privileges include USE CATALOG and USE SCHEMA to navigate, SELECT to read, MODIFY to write, CREATE to make new objects, and MANAGE to administer privileges and ownership. Administrators use SQL such as GRANT SELECT ON TABLE t TO \analytics`` and grant to groups rather than individuals.
  • Privilege inheritance across catalog, schema, and table. Grants cascade from parent to child, so a privilege granted at the catalog or schema level automatically applies to all current and future objects beneath it. Reading a table requires the full chain — USE CATALOG on the catalog, USE SCHEMA on the schema, and SELECT on the table or view — which keeps access explicit and predictable.
  • Groups and identity federation. Users and groups sync from your identity provider through SCIM, so membership is managed in the identity provider and reused across the platform. This keeps identity governance centralized and consistent as teams change.
  • Attribute-based access control (ABAC). ABAC governs access using governed tags rather than object-by-object grants. A policy attaches at a catalog, schema, or table and evaluates automatically for every matching object and its descendants; TO and EXCEPT clauses set who it applies to, and tag conditions decide which tables or columns it targets. One policy — for example, masking every column tagged as PII — can cover many tables, and it protects new datasets automatically as they are tagged. ABAC is generally available. See how to scale data governance with ABAC.
  • Row filters and column masks. row filters and column masks provide fine-grained control inside a table: row filters limit which rows a user sees, and column masks transform sensitive values before they are returned. Both are evaluated at query time, so they cannot be bypassed with a SELECT *. ABAC applies these at scale through tags, while table-level filters and masks handle per-table logic.
  • Consistent enforcement everywhere. Because Unity Catalog is the single authorization engine and enforcement fires at the SQL-engine level, the same grants, row filters, and column masks apply regardless of which service issues the query — SQL, notebooks, jobs, BI tools, or AI such as Genie and Agent Bricks — and applications cannot bypass governance. Policies on tables reached through views or functions evaluate against the identity of the person running the query.
  • Workspace-level scoping. Workspace bindings restrict which workspaces can access specific catalogs, external locations, and storage credentials, adding an environment-level boundary on top of object privileges.

Getting started

FAQs

How does Databricks decide what a user can access?

Unity Catalog is deny-by-default and grants access through explicit privileges on securable objects. Administrators use GRANT and REVOKE — typically to groups — and privileges such as USE CATALOG, USE SCHEMA, SELECT, MODIFY, CREATE, and MANAGE control navigation, reads, writes, creation, and administration.

What is ABAC and when should I use it?

Attribute-based access control uses governed tags to apply policies — such as row filters and column masks — across catalogs and schemas from a single definition. Use ABAC for centralized, tag-driven governance at scale; use table-level row filters and column masks when you need per-table logic.

Can I restrict access to specific rows or columns?

Yes. Row filters limit which rows a user can see, and column masks transform sensitive values before they are returned. Both are evaluated at query time, so they cannot be bypassed with a SELECT *, and they apply across SQL, notebooks, jobs, and BI tools.

Do permissions apply the same way across tools?

Yes. Unity Catalog is the single authorization engine and enforces at the SQL-engine level, so the same grants, row filters, and column masks apply whether the query comes from SQL, notebooks, jobs, BI tools, or AI such as Genie and Agent Bricks.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.