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 Icon Shared folder. You can grant Can Manage permission to notebooks and folders by moving them to the Shared Icon 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 Folder Icon Documents and Folder Icon 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.

  1. Select Permissions from the drop-down menu for the notebook, folder, or repo:

    Folder permissions Drop Down

  2. 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:

    Add notebook and folder users

    To change the permissions of a user or group, select the new permission from the permission drop-down:

    Change notebook and folder permissions

  3. 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 three button icon 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.

  1. Click Share.

    Experiment page permissions button

  2. In the dialog, click the Select User, Group or Service Principal… drop-down and select a user, group, or service principal.

    Permissions Settings dialog

  3. Select a permission from the permission drop-down.

  4. Click Add.

  5. If you want to remove a permission, click x for that user, group, or service principal.

    remove permission

  6. Click Save or Cancel.

Configure MLflow experiment permissions from the workspace

  1. To open the permissions dialog, select Permissions in the experiment’s drop-down menu.

    Workspace experiment permissions Drop Down

  2. 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:

    Add MLflow experiment users

    To change existing permissions, select the new permission from the permission drop-down:

    Change MLflow experiment permissions

    To remove a permission, click x for that user, group, or service principal.

  3. 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.

  1. Click Models Icon Models in the sidebar.

  2. Click a model name.

  3. Click Permissions.

    Model permissions button

  4. In the dialog, click the Select User, Group or Service Principal… drop-down and select a user, group, or service principal.

    Change MLflow model permissions

  5. Select a permission from the permission drop-down.

  6. Click Add.

  7. 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.

  1. Click Models Icon in the sidebar.

  2. Click Permissions.

    Registry model permissions drop down

  3. 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”.

    Inherited model permissions

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

Library icon All users can view libraries. To control who can attach libraries to clusters, see Cluster access control.

Schedule jobs - notebook icon 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.