Set permissions for resources in Databricks Asset Bundles

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

In Azure Databricks bundle configuration files, you can define permissions to apply to all resources defined in the bundle, or you can define one or more 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 experiments, jobs, models, and pipelines defined in resources using the top-level permissions mapping. See permissions.

Databricks recommends this approach for managing Databricks Asset Bundles resource permissions.

Define permissions for a specific resource

You can use the permissions mapping in an 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 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 levels for each resource are the following:
  • 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.

For information about specific permission levels, see:

• Experiments: MLflow experiment ACLs
• Jobs: Job ACLs
• Models: MLflow model ACLs
• Pipelines: Delta Live Tables pipeline ACLs

Note

Allowed permission levels for resources cannot necessarily be applied to resources using the top-level permissions mapping. For valid permission levels for the permissions mapping, see 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"
          }
        ],
        "...": "..."
      }
    }
  }
}