Databricks Workspace ACL Enforcement

[APJESK]

Databricks Workspace ACL Enforcement – How to Prevent Users from Creating Objects Outside Team Folder and Attaching to Shared Clusters?

Background

I am configuring workspace-level access control in Databricks to restrict Data Engineers (DE group) to operate only inside a dedicated team folder and to prevent unintended compute usage.

Here is the setup I implemented:

Configuration Details

Identity & Group Setup

• Created a user and added the user to DE-grp

• Assigned Workspace User role to DE-grp

• Applied default workspace entitlements

Folder Permissions

• Created a workspace folder:
  /Team/DatabricksEngineering

• Assigned CAN MANAGE permission to DE-grp

• No permissions were granted to DE-grp on other workspace folders

Compute Permissions

• Admin created shared clusters

• Granted Attach To permission to DE-grp

• DE-grp does NOT have permission to create clusters

Expected Behavior

I expected the following:

• Users in DE-grp should only create and manage notebooks inside:
  /Team/DatabricksEngineering

• Users should NOT be able to:

  • Create workspace objects outside this folder

  • Attach notebooks to shared clusters unless explicitly allowed

Observed Behavior (Problem)

When logging in as a DE-grp user:

1. Workspace Object Scope Leak

   • User can still create notebooks inside their personal Home folder:
     /Users/<username>

   • Since the user owns their Home folder, they automatically get CAN MANAGE permission

   • This bypasses folder-based governance

2. Compute Access Gap

   • Even though the user cannot create clusters:

   • They can still attach their notebooks which they created in Home folder to existing shared clusters and execute code

[pradeep_singh]

This behavior is expected with Databricks Workspace ACLs: you can’t disable a user’s Home folder or restrict object creation there, and cluster “Attach To” permissions are independent of the notebook’s location

[SteveOstrowski]

Hi @APJESK,

The two behaviors you are observing are both by design in how Databricks workspace ACLs work. Let me walk through each one and then cover what you can do to tighten governance.

ISSUE 1: USERS CAN CREATE NOTEBOOKS IN THEIR HOME FOLDER

Every Databricks user automatically gets a personal home folder at /Users/<username> and has CAN MANAGE permission on it. This is a built-in platform behavior and cannot be removed or overridden by workspace admins. There is no workspace setting or ACL configuration that prevents a user from creating objects inside their own home folder.

This means that even if you only grant DE-grp the CAN MANAGE permission on /Team/DatabricksEngineering and nothing else, users will still be able to create notebooks, files, and other objects in their personal /Users/<username> directory.

Reference: https://docs.databricks.com/en/security/auth-authz/access-control/index.html

ISSUE 2: USERS CAN ATTACH HOME FOLDER NOTEBOOKS TO SHARED CLUSTERS

Compute permissions (CAN ATTACH TO, CAN RESTART, CAN MANAGE) are evaluated independently from workspace folder permissions. If a user has CAN ATTACH TO on a shared cluster, they can attach any notebook they have permission to run, regardless of where that notebook lives in the workspace. Since users own their home folder notebooks (CAN MANAGE), they can attach and execute those notebooks on any cluster they have CAN ATTACH TO permission for.

This is the expected behavior. The CAN ATTACH TO permission grants the ability to use that compute resource, and it does not check which folder the notebook is stored in.

WHAT YOU CAN DO TO STRENGTHEN GOVERNANCE

While you cannot prevent home folder usage or location-based compute restrictions through workspace ACLs alone, there are several complementary approaches you can layer together:

1. Use Unity Catalog for data governance
Rather than trying to control where notebooks live, focus on controlling what data users can access. Unity Catalog lets you grant and revoke fine-grained permissions (SELECT, MODIFY, CREATE, etc.) on catalogs, schemas, and tables. Even if a user runs a notebook from their home folder, they can only access the data their group is authorized to use.

Reference: https://docs.databricks.com/en/data-governance/unity-catalog/manage-privileges/index.html

2. Use Standard access mode (shared clusters with user isolation)
When you configure shared clusters with Standard access mode, each user's code runs with their own identity. This means Unity Catalog permissions are enforced per user, even on a shared cluster. A user in DE-grp running a notebook from their home folder would still be limited to only the data their group has been granted access to.

Reference: https://docs.databricks.com/en/compute/configure.html

3. Use cluster policies to restrict cluster creation
You mentioned that DE-grp cannot create clusters, which is correct. You can further enforce this by using cluster policies. Policies let you control which configurations are allowed, limit the maximum number of clusters per user, and restrict compute resource consumption.

Reference: https://docs.databricks.com/en/admin/clusters/policies.html

4. Remove the "Unrestricted cluster creation" entitlement
Make sure the "Allow unrestricted cluster creation" entitlement is not granted to DE-grp or its members. This ensures they cannot create clusters outside of what policies allow. You can verify this in Admin Settings under the group's entitlements.

Reference: https://docs.databricks.com/en/admin/users-groups/index.html

5. Audit and monitor with system tables
Databricks system tables (audit logs) let you track who is creating objects, where they are creating them, and what clusters they are attaching to. You can set up alerts for unexpected activity, such as notebook creation outside of approved folders.

Reference: https://docs.databricks.com/en/admin/system-tables/index.html

SUMMARY

The core principle is: workspace folder ACLs control who can see and edit objects in a given location, but they do not restrict where users can create objects (users always have their home folder) or which clusters they can use (that is governed by compute permissions separately). The recommended approach is to combine workspace ACLs with Unity Catalog data permissions, Standard access mode clusters, and cluster policies to build a comprehensive governance model.

This layered approach gives you control over what data users can access and what compute resources they can use, which is ultimately more robust than trying to restrict where notebooks are stored.

* This reply used an agent system I built to research and draft this response based on the wide set of documentation I have available and previous memory. I personally review the draft for any obvious issues and for monitoring system reliability and update it when I detect any drift, but there is still a small chance that something is inaccurate, especially if you are experimenting with brand new features.