Set permissions for resources in Databricks Asset Bundles

This article describes how to set permissions for resources in Databricks Asset Bundles. For information about resources supported in bundles, see Databricks Asset Bundles resources.

In Databricks bundle configuration files, you can define permissions at the top level to apply to all resources defined in the bundle, or you can define permissions to apply to specific resources.

note

Permissions cannot overlap. In other words, permissions for a user, group, or service principal cannot be defined in both the top-level permissions mapping and within the resources mapping.

Define permissions to apply to all resources

You can define permissions to apply to all supported resources defined in resources using the top-level permissions mapping. Databricks recommends this approach for managing Databricks Asset Bundles resource permissions.

Permissions define the allowed permissions level for a user_name, group_name, or service_principal_name. Allowed top-level permission levels are CAN_VIEW, CAN_MANAGE, and CAN_RUN. For more information about the top-level permissions mapping, see permissions.

The following example sets top-level permissions for the dev target. The user someone@example.com will have CAN_RUN permissions on my-job:

YAML

bundle:
  name: my-bundle

resources:
  jobs:
    my-job:
      # ...

targets:
  dev:
    # ...
    permissions:
      - user_name: someone@example.com
        level: CAN_RUN

Define permissions for a specific resource

You can use the permissions mapping in a dashboard, experiment, job, model, or pipeline definition in resources to define one or more permissions for that resource.

Each permission in the permissions mapping must include the following:

• Either user_name, group_name, or service_principal_name, set to the name of the user, group, or service principal, respectively.
• level, set to the name of the permission level. Allowed permission levels for each resource are the following:
  • Dashboards: CAN_EDIT, CAN_MANAGE CAN_VIEW, and CAN_READ.
  • Experiments: CAN_EDIT, CAN_MANAGE and CAN_READ.
  • Jobs: CAN_MANAGE, CAN_MANAGE_RUN, CAN_VIEW, 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.

important

Allowed permission levels for resources cannot necessarily be applied to resources using the top-level permissions mapping. For valid permission levels for the top-level permissions mapping, see permissions.

The following syntax shows how to declare permissions for a resource type (in this example, pipelines) in the top-level resources mapping and in a resources mapping within a target:

YAML

# ...
resources:
  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>
      # ...

YAML

targets:
  <some-programmatic-identifier-for-this-target>:
    resources:
      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:

YAML

bundle:
  name: my-bundle

resources:
  jobs:
    my-job:
      # ...
      permissions:
        - group_name: test-group
          level: CAN_VIEW
      # ...

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

When you run databricks bundle validate for this example, the resulting graph is as follows:

JSON

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

Permissions order of precedence

If you have permissions defined in multiple places in your bundle configuration, the permissions granted to resources, workspace directories, and files specified in the bundle are in the following order:

1. The permissions defined for the resource in the target deployment
2. The permissions defined for the target deployment
3. The permissions defined for the resource in the bundle
4. The permissions defined in the bundle's top-level permissions

For example, in the following configuration, the group test-group will have CAN_MANAGE permissions for the job in the dev target, but CAN_MANAGE_RUN permissions for the job in the prod target:

YAML

bundle:
  name: my-bundle

permissions:
  - group_name: test-group
    level: CAN_VIEW

resources:
  jobs:
    my-job:
      # ...
      permissions:
        - group_name: test-group
          level: CAN_MANAGE_RUN
      # ...

targets:
  dev:
    # ...
    resources:
      jobs:
        my-job:
          # ...
          permissions:
            - group_name: test-group
              level: CAN_MANAGE
          # ...
  prod:
    # ...
    resources:
      jobs:
        my-job:
          # ...