Databricks Community

saurabh18cs · Friday

I’m exploring how to set up exclusive access for separate use cases implementation within a shared Databricks workspace, using Microsoft Entra groups and Unity Catalog. I’d love to hear from anyone who has implemented something similar, or is currently working through the same questions.

A few things I’m trying to understand:

How have you structured Unity Catalog privileges to keep use cases isolated while allowing catalog admins to manage the catalog?
Have you delegated schema-level permission management to use-case owners? What worked well, and what should we watch out for?

suranga · Friday

Hi @saurabh18cs,

This is one of those setups where it really pays to settle the pattern early, before there are hundreds of grants to untangle. Here's how I'd structure it:

1. Account groups only. Sync the Entra groups into the Databricks account (automatic identity management or SCIM) and grant to those. Workspace-local groups can't be granted access to Unity Catalog data at all, so they're a dead end here.

2. A few groups per use case, for example uc_sales_owners, uc_sales_writers and uc_sales_readers. Make groups the owners of things, never individual people, so nothing breaks when someone leaves.

3. Keep the catalog with the platform team and delegate at schema level. The catalog admin group owns the catalog. Each use case gets USE CATALOG on the catalog plus MANAGE on its own schema. MANAGE lets the use-case owners handle grants inside their schema without being the owner, and they can't touch anything else in the catalog:

GRANT USE CATALOG ON CATALOG analytics TO `uc_sales_owners`;
GRANT MANAGE, USE SCHEMA, CREATE TABLE ON SCHEMA analytics.sales TO `uc_sales_owners`;

Things to watch out for:

Privileges inherit downwards. A SELECT granted on the catalog applies to every schema in it, so give use-case groups nothing on the catalog except USE CATALOG (and BROWSE if you want people to discover other datasets without being able to read them).
Delegation means trust. Someone with MANAGE on a schema can grant it to any group, including other use cases. Agree the rules up front and check system.access.audit now and then.
If use cases also need separate storage, give each schema its own managed location, and keep external locations and storage credentials with the platform team.
Unity Catalog doesn't cover workspace objects. Notebooks, jobs, clusters and warehouses have their own permissions, so mirror the same groups there (a folder per use case, cluster policies per group).
If a use case needs harder separation than a schema in a shared catalog, a catalog per use case bound to specific workspaces is the next step up.

Hope that helps. Happy to compare notes if you run into something specific.

Cheers,
Suranga

DoTA · 7 hours ago

The grant layout above is the right base. Two things from the ownership docs that are easy to miss when you promise "exclusive" access.

First, exclusive has a ceiling. Metastore admins can view all grants and transfer ownership of any object, and account and workspace admins have default privileges for managing Unity Catalog. So the isolation holds against regular users, and you still need to decide who carries those admin roles and keep that list short and audited.

Second, if use-case owners create views, functions or models and you want a group to own them, there is a catch. Only a metastore admin can hand those to any group. Owners and MANAGE holders can only transfer them to themselves or to a group they belong to. So either have the owners do the handover while they are still members, or plan a platform-team step for it, otherwise a view can end up owned by someone who has left.

Louis_Frolio · 6 hours ago

Greetings @saurabh18cs, I did some digging and here is what I found.

First, credit to @suranga and @DoTA. Suranga's layout is the one I'd start from: account groups synced from Entra, a small set of groups per use case, the platform team owns the catalog, and each use case gets USE CATALOG plus MANAGE on its own schema. DoTA's points about the admin ceiling and the ownership-transfer rule for views, functions and models come straight from the docs. I'll build on both rather than repeat them.

Short answer to your two questions: yes, delegate at schema level with MANAGE, and keep catalog ownership, storage credentials, external locations and all catalog-level grants with the platform team. Then plan for the following.

Catalog-level grants break isolation. Privileges inherit down to every current and future schema, and there's no way to revoke an exception lower down. Keep the catalog to USE CATALOG. Granting BROWSE to all account users is a reasonable add, so other teams can discover datasets and request access without reading them.
Admins can always reach the data. MANAGE doesn't include SELECT, but a MANAGE holder can grant themselves whatever they're missing, and catalog owners, metastore admins and account admins can do the same. So "exclusive" holds against regular users, not against platform staff. Make a small group (say uc_platform_admins) the catalog owner and watch system.access.audit for permission and ownership changes. If the business needs separation even from the platform team, that's an operating-model decision, not something grants enforce.
Nested groups under automatic identity management. AIM is the default for new accounts and the recommended path over SCIM. It honors nested membership, but a nested group isn't referenceable in Unity Catalog until it's provisioned to the account. If you want to grant to uc_sales_readers directly, add that group to the account or a workspace; don't rely on it being a child of a parent group.
Who owns new tables. MANAGE on the schema doesn't change ownership of what gets created inside it. Whoever runs CREATE TABLE owns it. Run production pipelines as a service principal that belongs to the owners group so ownership never leaves with an employee, and for interactive work finish with ALTER TABLE analytics.sales.orders OWNER TO \uc_sales_owners``. Tables can go to any group. Per DoTA, views, functions and models can only go to a group the current owner belongs to, unless a metastore admin does the transfer.
Self-audit has a blind spot. A MANAGE holder currently sees only their own grants in information_schema. SHOW GRANTS ON SCHEMA analytics.sales and the Permissions tab in Catalog Explorer show everything. The docs say this will be corrected, so plan around it today.
Don't build on the workspace catalog. If the workspace was enabled for Unity Catalog automatically, every workspace user already has USE CATALOG there plus create privileges on its default schema. Make a dedicated catalog for this pattern.
Workspace objects aren't covered. Notebooks, folders, jobs, clusters, SQL warehouses and secret scopes have their own permissions. Mirror the same Entra groups there (a folder per use case, cluster policies per group) so code and credentials don't leak between use cases.
When schema-per-use-case isn't enough. Catalog per use case plus workspace-catalog binding is a hard boundary on top of grants: a user holding SELECT still can't reach the catalog from an unbound workspace. Take that step when owners need their own schemas and managed storage, or when "exclusive" is a compliance word rather than a convenience word. If use cases must share tables but see different rows, ABAC row filters and column masks are the tool, not more schemas.

The grants for one use case end up looking like this:

GRANT USE CATALOG ON CATALOG analytics TO `uc_sales_owners`;
GRANT MANAGE, USE SCHEMA, CREATE TABLE ON SCHEMA analytics.sales TO `uc_sales_owners`;
GRANT USE CATALOG ON CATALOG analytics TO `uc_sales_readers`;
GRANT USE SCHEMA, SELECT ON SCHEMA analytics.sales TO `uc_sales_readers`;

References: