Set permissions for resources in Databricks Asset Bundles
Preview
This feature is in Public 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
, orservice_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
andCAN_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
, 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: 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"
}
],
"...": "..."
}
}
}
}