Skip to main content

Set permissions for resources in Databricks Asset Bundles

This article describes how to set permissions for Lakeflow Jobs, Lakeflow Declarative Pipelines, and MLOps Stacks in Databricks Asset Bundles. See What are Databricks Asset Bundles?.

In 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. Allowed top-level permission levels are CAN_VIEW, CAN_MANAGE, and CAN_RUN.

For more information on 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:

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):

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

YAML
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_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",
            "user_name": "someone@example.com"
          },
          {
            "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:
          # ...
Last updated on