Set permissions for resources in Databricks Asset Bundles
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 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
, orservice_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
andCAN_READ
.Jobs:
CAN_MANAGE
,CAN_MANAGE_RUN
,CAN_VIEW
, andIS_OWNER
.Models:
CAN_EDIT
,CAN_MANAGE
,CAN_MANAGE_STAGING_VERSIONS
,CAN_MANAGE_PRODUCTION_VERSIONS
, andCAN_READ
.Pipelines:
CAN_MANAGE
,CAN_RUN
,CAN_VIEW
, andIS_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"
}
],
"...": "..."
}
}
}
}