Set permissions for resources in Databricks Asset Bundles

Preview

This article describes how to set permissions for Databricks jobs, Delta Live Tables pipelines, and MLOps Stacks in Databricks Asset Bundles. See What are Databricks Asset Bundles?.

In Databricks bundle configuration files, you use the permissions array in an experiment, job, model, or pipeline definition in resources to define one or more permissions for that resource.

Each permission in the permissions array must include the following two mappings:

Either user_name, group_name, or service_principal_name, with the name of the user, group, or service principal, respectively.
level, with the name of the permission level. Allowed permission level names include the following:
- Experiments: CAN_EDIT, CAN_MANAGE and CAN_READ.
- Jobs: CAN_BIND, CAN_ATTACH_TO, CAN_EDIT, CAN_EDIT_METADATA, CAN_MANAGE, CAN_MANAGE_PRODUCTION_VERSIONS, CAN_MANAGE_RUN, CAN_READ, CAN_RESTART, CAN_RUN, CAN_USE, CAN_VIEW, CAN_VIEW_METADATA, and IS_OWNER.
- Models: CAN_EDIT, CAN_MANAGE, CAN_MANAGE_STAGING_VERSIONS, CAN_MANAGE_PRODUCTION_VERSIONS, and CAN_READ.
- Pipelines: CAN_MANAGE, CAN_RUN, CAN_VIEW, and IS_OWNER.

For information about specific permission levels, see:

Experiments: Share experiments
Jobs: Job permissions
Models: Share MLflow Models
Pipelines: Delta Live Tables permissions

The following syntax shows how to declare multiple permissions for each resource type, either in the top-level resources mapping or a resources mapping within a target (ellipses indicate omitted content, for brevity):

# ...
resources:
  experiments:
    <some-programmatic-identifier-for-this-experiment>:
      # ...
      permissions:
        - user_name: <user-name> # Or:
          group_name: <group-name> # Or:
          service_principal_name: <service-principal-name>
          level: <permission-level>
      # ...
  jobs:
    <some-programmatic-identifier-for-this-job>:
      # ...
      permissions:
        - user_name: <user-name> # Or:
          group_name: <group-name> # Or:
          service_principal_name: <service-principal-name>
          level: <permission-level>
      # ...
  models:
    <some-programmatic-identifier-for-this-model>:
      # ...
      permissions:
        - user_name: <user-name> # Or:
          group_name: <group-name> # Or:
          service_principal_name: <service-principal-name>
          level: <permission-level>
      # ...
  pipelines:
    <some-programmatic-identifier-for-this-pipeline>:
      # ...
      permissions:
        - user_name: <user-name> # Or:
          group_name: <group-name-1> # Or:
          service_principal_name: <service-principal-name>
          level: <permission-level>
      # ...

targets:
  <some-programmatic-identifier-for-this-target>:
    resources:
      experiments:
        <some-programmatic-identifier-for-this-experiment>:
          # ...
          permissions:
            - user_name: <user-name> # Or:
              group_name: <group-name> # Or:
              service_principal_name: <service-principal-name>
              level: <permission-level>
          # ...
      jobs:
        <some-programmatic-identifier-for-this-job>:
          # ...
          permissions:
            - user_name: <user-name> # Or:
              group_name: <group-name> # Or:
              service_principal_name: <service-principal-name>
              level: <permission-level>
          # ...
      models:
        <some-programmatic-identifier-for-this-model>:
          # ...
          permissions:
            - user_name: <user-name> # Or:
              group_name: <group-name> # Or:
              service_principal_name: <service-principal-name>
              level: <permission-level>
          # ...
      pipelines:
        <some-programmatic-identifier-for-this-pipeline>:
          # ...
          permissions:
            - user_name: <user-name> # Or:
              group_name: <group-name> # Or:
              service_principal_name: <service-principal-name>
              level: <permission-level>
          # ...
    # ...

Any permissions that are declared for a resource in the top-level resources mapping are combined with any permissions that are declared for that same resources mapping in an individual target. For example, given the following resources mapping for the same resource at both the top level and in a target (ellipses indicate omitted content, for brevity):

bundle:
  name: my-bundle

resources:
  jobs:
    my-job:
      # ...
      permissions:
        - user_name: someone@example.com
          level: CAN_VIEW
      # ...

targets:
  dev:
    # ...
    resources:
      jobs:
        my-job:
          # ...
          permissions:
            - user_name: someone@example.com
              level: CAN_RUN
          # ...

When you run databricks bundle validate for this example, the resulting graph is as follows (ellipses indicate omitted content, for brevity):

{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "permissions": [
          {
            "level": "CAN_VIEW",
            "user_name": "someone@example.com"
          },
          {
            "level": "CAN_RUN",
            "user_name": "someone@example.com"
          }
        ],
        "...": "..."
      }
    }
  }
}