Workspace object access control
Note
Access control is available only in the Premium plan.
With workspace object access control, individual permissions determine a user’s abilities to modify workspace objects. This article describes the individual permissions and how to configure workspace object access control.
Tip
You can manage permissions in a fully automated setup using Databricks Terraform provider and databricks_permissions.
Before you can use workspace object access control, a Databricks workspace admin must enable it for the workspace. See Enable access control.
Folder permissions
You can assign five permission levels to folders: No Permissions, Can Read, Can Run, Can Edit, and Can Manage. The table lists the abilities for each permission.
Ability |
No Permissions |
Can Read |
Can Run |
Can Edit |
Can Manage |
---|---|---|---|---|---|
List items in folder |
x |
x |
x |
x |
x |
View items in folder |
x |
x |
x |
x |
|
Clone and export items |
x |
x |
x |
x |
|
Create, import, and delete items |
x |
||||
Move and rename items |
x |
||||
Change permissions |
x |
Notebooks and experiments in a folder inherit all permissions settings of that folder. For example, a user that has Can Run permission on a folder has Can Run permission on the notebooks in that folder.
Default folder permissions
Independent of workspace object access control, the following permissions exist:
All users have Can Manage permission for items in the Workspace >
Shared folder. You can grant Can Manage permission to notebooks and folders by moving them to the
Shared folder.
All users have Can Manage permission for objects the user creates.
With workspace object access control disabled, the following permissions exist:
All users have Can Edit permission for items in the Workspace folder.
With workspace object access control enabled, the following permissions exist:
Workspace folder
Only workspace administrators can create new items in the Workspace folder.
Existing items in the Workspace folder - Can Manage. For example, if the Workspace folder contained the
Documents and
Temp folders, all users continue to have the Can Manage permission for these folders.
New items in the Workspace folder - No Permissions.
A user has the same permission for all items in a folder, including items created or moved into the folder after you set the permissions, as the permission the user has on the folder.
User home directory - The user has Can Manage permission. All other users have No Permissions permission.
Notebook permissions
You can assign five permission levels to notebooks: No Permissions, Can Read, Can Run, Can Edit, and Can Manage. The table lists the abilities for each permission.
Ability |
No Permissions |
Can Read |
Can Run |
Can Edit |
Can Manage |
---|---|---|---|---|---|
View cells |
x |
x |
x |
x |
|
Comment |
x |
x |
x |
x |
|
Run via %run or notebook workflows |
x |
x |
x |
x |
|
Attach and detach notebooks |
x |
x |
x |
||
Run commands |
x |
x |
x |
||
Edit cells |
x |
x |
|||
Change permissions |
x |
File permissions
You can assign five permission levels to files: No Permissions, Can Read, Can Run, Can Edit, and Can Manage. The table lists the abilities for each permission.
Ability |
No Permissions |
Can Read |
Can Run |
Can Edit |
Can Manage |
---|---|---|---|---|---|
Read file |
x |
x |
x |
x |
|
Comment |
x |
x |
x |
x |
|
Attach and detach file (.py, .R, .sql, .scala) |
x |
x |
x |
||
Run file interactively (.py, .R, .sql, .scala) |
x |
x |
x |
||
Edit file |
x |
x |
|||
Change permissions |
x |
Repos permissions
You can assign five permission levels to repos: No Permissions, Can Read, Can Run, Can Edit, and Can Manage. The table lists the abilities for each permission.
Ability |
No Permissions |
Can Read |
Can Run |
Can Edit |
Can Manage |
---|---|---|---|---|---|
List items in repo |
x |
x |
x |
x |
x |
View items in repo |
x |
x |
x |
x |
|
Clone and export items |
x |
x |
x |
x |
|
Run notebooks in repo |
x |
x |
x |
||
Edit notebooks in repo |
x |
x |
|||
Create, import, and delete items |
x |
||||
Move and rename items |
x |
||||
Change permissions |
x |
Configure notebook, folder, and repos permissions
Note
This section describes how to manage permissions using the UI. You can also use the Permissions API.
Select Permissions from the drop-down menu for the notebook, folder, or repo:
To grant permissions to a user or group, select from the Add Users, Groups, and Service Principals drop-down, select the permission, and click Add:
To change the permissions of a user or group, select the new permission from the permission drop-down:
After you make changes in the dialog, Done changes to Save Changes and a Cancel button appears. Click Save Changes or Cancel.
MLflow Experiment permissions
You can assign four permission levels to MLflow Experiments: No Permissions, Can Read, Can Edit, and Can Manage. The table lists the abilities for each permission.
Note
You cannot directly set permissions on an MLflow experiment that was created by a notebook in a Databricks Repo. The permissions set at the Repo level control access to experiments created by notebooks in the Repo.
Ability |
No Permissions |
Can Read |
Can Edit |
Can Manage |
---|---|---|---|---|
View run info, search, compare runs |
x |
x |
x |
|
View, list, and download run artifacts |
x |
x |
x |
|
Create, delete, and restore runs |
x |
x |
||
Log run params, metrics, tags |
x |
x |
||
Log run artifacts |
x |
x |
||
Edit experiment tags |
x |
x |
||
Purge runs and experiments |
x |
|||
Grant permissions |
x |
Note
Experiment permissions are only enforced on artifacts stored in DBFS locations managed by MLflow. For more information, see MLflow Artifact permissions.
Create, delete, and restore experiment requires Can Edit or Can Manage access to the folder containing the experiment.
You can specify the Can Run permission for experiments. It is enforced the same way as Can Edit.
Configure MLflow experiment permissions
You can configure MLflow experiment permissions from the experiments page, the experiment page, or from the workspace.
Configure MLflow experiment permissions from the experiments page
You can change permissions for an experiment that you own from the experiments page. Click in the Actions column and select Permissions.
Configure MLflow experiment permissions from the experiment page
All users in your account belong to the group all users
. Administrators belong to the group admins
, which has Manage permissions on all objects.
Note
Permissions you set in this dialog apply to the notebook that corresponds to this experiment.
Click Share.
In the dialog, click the Select User, Group or Service Principal… drop-down and select a user, group, or service principal.
Select a permission from the permission drop-down.
Click Add.
If you want to remove a permission, click
for that user, group, or service principal.
Click Save or Cancel.
Configure MLflow experiment permissions from the workspace
To open the permissions dialog, select Permissions in the experiment’s drop-down menu.
Grant or remove permissions. All users in your account belong to the group all users. Administrators belong to the group admins, which has Can Manage permissions on all items.
To grant permissions, select from the Select User, Group, or Service Principal drop-down, select the permission, and click Add:
To change existing permissions, select the new permission from the permission drop-down:
To remove a permission, click
for that user, group, or service principal.
After you make changes in the dialog, click Save or Cancel.
MLflow Artifact permissions
Each MLflow Experiment has an Artifact Location that
is used to store artifacts logged to MLflow runs. Starting in MLflow 1.11, artifacts are stored in an
MLflow-managed subdirectory of the Databricks File System (DBFS) by default.
MLflow experiment permissions apply to artifacts stored in these managed
locations, which have the prefix dbfs:/databricks/mlflow-tracking
. To download or log an artifact, you must
have the appropriate level of access to its associated MLflow experiment.
Note
Artifacts stored in MLflow-managed locations can only be accessed using the MLflow Client (version
1.9.1
or later), which is available for Python, Java, and R. Other access mechanisms, such as dbutils and the DBFS API, are not supported for MLflow-managed locations.You can also specify your own artifact location when creating an MLflow experiment. Experiment access controls are not enforced on artifacts stored outside of the default MLflow-managed DBFS directory.
MLflow Model permissions
You can assign six permission levels to MLflow Models registered in the MLflow Model Registry: No Permissions, Can Read, Can Edit, Can Manage Staging Versions, Can Manage Production Versions, and Can Manage. The table lists the abilities for each permission.
Note
A model version inherits permissions from its parent model; you cannot set permissions for model versions.
Ability |
No Permissions |
Can Read |
Can Edit |
Can Manage Staging Versions |
Can Manage Production Versions |
Can Manage |
---|---|---|---|---|---|---|
Create a model |
x |
x |
x |
x |
x |
x |
View model details, versions, stage transition requests, activities, and artifact download URIs |
x |
x |
x |
x |
x |
|
Request a model version stage transition |
x |
x |
x |
x |
x |
|
Add a version to a model |
x |
x |
x |
x |
||
Update model and version description |
x |
x |
x |
x |
||
Add or edit tags for a model or model version |
x |
x |
x |
x |
||
Transition model version between stages |
x (between None, Archived, and Staging) |
x |
x |
|||
Approve or reject a model version stage transition request |
x (between None, Archived, and Staging) |
x |
x |
|||
Cancel a model version stage transition request (see Note) |
x |
|||||
Modify permissions |
x |
|||||
Rename model |
x |
|||||
Delete model and model versions |
x |
Note
The creator of a stage transition request can also cancel the request.
Default MLflow Model permissions
Independent of workspace object access control, the following permissions exist:
All users have permission to create a new registered model.
All workspace administrators have Manage permission for all models.
With workspace object access control disabled, the following permissions exist:
All users have Manage permission for all models.
With workspace object access control enabled, the following default permissions exist:
All users have Manage permission for models the user creates.
Non-administrator users have No Permissions on models they did not create.
Configure MLflow Model permissions
All users in your account belong to the group all users
. Workspace administrators belong to the group admins
, which has Manage permissions on all objects.
Note
This section describes how to manage permissions using the UI. You can also use the Permissions API.
Click
Models in the sidebar.
Click a model name.
Click Permissions.
In the dialog, click the Select User, Group or Service Principal… drop-down and select a user, group, or service principal.
Select a permission from the permission drop-down.
Click Add.
Click Save or Cancel.
Configure permissions for all MLflow Models in Model Registry
Workspace administrators can set permission levels on all models for specific users or groups in Model Registry using the UI.
Click
in the sidebar.
Click Permissions.
Follow the steps listed in Configure MLflow Model permissions, starting at step 4.
When you navigate to a specific model page, permissions set at the registry-wide level are marked “inherited”.
Note
A user with Can Manage permission at the registry-wide level can change registry-wide permissions for all other users.
MLflow Model Artifact permissions
The model files for each MLflow model version are stored in an MLflow-managed location, with the prefix dbfs:/databricks/mlflow-registry/
.
To get the exact location of the files for a model version, you must have Read access to the model. Use the REST API endpoint /api/2.0/mlflow/model-versions/get-download-uri
.
After obtaining the URI, you can use the DBFS API to download the files.
The MLflow Client (for Python, Java, and R) provides several convenience methods that wrap this workflow to download and load the model, such as mlflow.<flavor>.load_model()
.
Note
Other access mechanisms, such as dbutils and %fs
are not supported for MLflow-managed file locations.
Library and jobs access control
All users can view libraries. To control who can attach libraries to clusters, see Cluster access control.
To control who can run jobs and see the results of job runs, see Jobs access control.
Terraform integration
You can manage permissions in a fully automated setup using Databricks Terraform provider and databricks_permissions:
resource "databricks_group" "auto" {
display_name = "Automation"
}
resource "databricks_group" "eng" {
display_name = "Engineering"
}
resource "databricks_notebook" "this" {
content_base64 = base64encode("# Welcome to your Python notebook")
path = "/Production/ETL/Features"
language = "PYTHON"
}
resource "databricks_permissions" "notebook_usage" {
notebook_path = databricks_notebook.this.path
access_control {
group_name = "users"
permission_level = "CAN_READ"
}
access_control {
group_name = databricks_group.auto.display_name
permission_level = "CAN_RUN"
}
access_control {
group_name = databricks_group.eng.display_name
permission_level = "CAN_EDIT"
}
}
Tip
You can get a list of notebooks’ paths (and their languages) for a workspace by using databricks_notebook_paths.