This resource allows you to generically manage permissions for other resources in Databricks workspace. It would guarantee, that only admins, authenticated principal and those declared within access_control blocks would have specified access. It is not possible to remove management rights from admins group.
It's possible to separate cluster access control to three different permission levels: CAN_ATTACH_TO, CAN_RESTART and CAN_MANAGE:
resource "databricks_group" "auto" {
display_name = "Automation"
}
resource "databricks_group" "eng" {
display_name = "Engineering"
}
resource "databricks_group" "ds" {
display_name = "Data Science"
}
resource "databricks_cluster" "shared_autoscaling" {
cluster_name = "Shared Autoscaling"
spark_version = "6.6.x-scala2.11"
node_type_id = "Standard_DS3_v2"
autotermination_minutes = 60
autoscale {
min_workers = 1
max_workers = 10
}
}
resource "databricks_permissions" "cluster_usage" {
cluster_id = databricks_cluster.shared_autoscaling.cluster_id
access_control {
group_name = databricks_group.auto.display_name
permission_level = "CAN_ATTACH_TO"
}
access_control {
group_name = databricks_group.eng.display_name
permission_level = "CAN_RESTART"
}
access_control {
group_name = databricks_group.ds.display_name
permission_level = "CAN_MANAGE"
}
}Cluster policies allow creation of clusters, that match given policy. It's possible to assign CAN_USE permission to users and groups:
resource "databricks_group" "ds" {
display_name = "Data Science"
}
resource "databricks_group" "eng" {
display_name = "Engineering"
}
resource "databricks_cluster_policy" "something_simple" {
name = "Some simple policy"
definition = jsonencode({
"spark_conf.spark.hadoop.javax.jdo.option.ConnectionURL": {
"type": "forbidden"
},
"spark_conf.spark.secondkey": {
"type": "forbidden"
}
})
}
resource "databricks_permissions" "policy_usage" {
cluster_policy_id = databricks_cluster_policy.something_simple.id
access_control {
group_name = databricks_group.ds.display_name
permission_level = "CAN_USE"
}
access_control {
group_name = databricks_group.eng.display_name
permission_level = "CAN_USE"
}
}Instance Pools access control allows to assign CAN_ATTACH_TO and CAN_MANAGE permissions to users, service principals, and groups. It's also possible to grant creation of Instance Pools to individual groups and users, service principals.
resource "databricks_group" "auto" {
display_name = "Automation"
}
resource "databricks_group" "eng" {
display_name = "Engineering"
}
resource "databricks_instance_pool" "this" {
instance_pool_name = "Reserved Instances"
idle_instance_autotermination_minutes = 60
node_type_id = "i3.xlarge"
min_idle_instances = 0
max_capacity = 10
}
resource "databricks_permissions" "pool_usage" {
instance_pool_id = databricks_instance_pool.this.id
access_control {
group_name = databricks_group.auto.display_name
permission_level = "CAN_ATTACH_TO"
}
access_control {
group_name = databricks_group.eng.display_name
permission_level = "CAN_MANAGE"
}
}There are four assignable permission levels for databricks_job: CAN_VIEW, CAN_MANAGE_RUN, IS_OWNER, and CAN_MANAGE. Admins are granted the CAN_MANAGE permission by default, and they can assign that permission to non-admin users, and service principals.
- The creator of a job has
IS_OWNERpermission. Destroyingdatabricks_permissionsresource for a job would revert ownership to the creator. - A job must have exactly one owner. If resource is changed and no owner is specified, currently authenticated principal would become new owner of the job. Nothing would change, per se, if the job was created through Terraform.
- A job cannot have a group as an owner.
- Jobs triggered through Run Now assume the permissions of the job owner and not the user, and service principal who issued Run Now.
- Read main documentation for additional detail.
resource "databricks_group" "auto" {
display_name = "Automation"
}
resource "databricks_group" "eng" {
display_name = "Engineering"
}
resource "databricks_job" "this" {
name = "Featurization"
max_concurrent_runs = 1
email_notifications {}
new_cluster {
num_workers = 300
spark_version = "6.6.x-scala2.11"
node_type_id = "Standard_DS3_v2"
}
notebook_task {
notebook_path = "/Production/MakeFeatures"
}
}
resource "databricks_permissions" "job_usage" {
job_id = databricks_job.this.id
access_control {
group_name = "users"
permission_level = "CAN_VIEW"
}
access_control {
group_name = databricks_group.auto.display_name
permission_level = "CAN_MANAGE_RUN"
}
access_control {
group_name = databricks_group.eng.display_name
permission_level = "CAN_MANAGE"
}
}Valid permission levels for databricks_notebook are: CAN_READ, CAN_RUN, CAN_EDIT, and CAN_MANAGE.
resource "databricks_group" "auto" {
display_name = "Automation"
}
resource "databricks_group" "eng" {
display_name = "Engineering"
}
resource "databricks_notebook" "this" {
content_base64 = base64encode("# Welcome to your Python notebook")
path = "/Production/ETL/Features"
language = "PYTHON"
}
resource "databricks_permissions" "notebook_usage" {
notebook_path = databricks_notebook.this.path
access_control {
group_name = "users"
permission_level = "CAN_READ"
}
access_control {
group_name = databricks_group.auto.display_name
permission_level = "CAN_RUN"
}
access_control {
group_name = databricks_group.eng.display_name
permission_level = "CAN_EDIT"
}
}Valid permission levels for folders of databricks_notebook are: CAN_READ, CAN_RUN, CAN_EDIT, and CAN_MANAGE. Notebooks and experiments in a folder inherit all permissions settings of that folder. For example, a user (or service principal) that has CAN_RUN permission on a folder has CAN_RUN permission on the notebooks in that folder.
- All users can list items in the folder without any permissions.
- All users (or service principals) have
CAN_MANAGEpermission for items in the Workspace > Shared Icon Shared folder. You can grantCAN_MANAGEpermission to notebooks and folders by moving them to the Shared Icon Shared folder. - All users (or service principals) have
CAN_MANAGEpermission for objects the user creates. - User home directory - The user (or service principal) has
CAN_MANAGEpermission. All other users (or service principals) can list their directories.
resource "databricks_group" "auto" {
display_name = "Automation"
}
resource "databricks_group" "eng" {
display_name = "Engineering"
}
resource "databricks_notebook" "this" {
content_base64 = base64encode("# Welcome to your Python notebook")
path = "/Production/ETL/Features"
language = "PYTHON"
}
resource "databricks_permissions" "folder_usage" {
directory_path = "/Production/ETL"
depends_on = [databricks_notebook.this]
access_control {
group_name = "users"
permission_level = "CAN_READ"
}
access_control {
group_name = databricks_group.auto.display_name
permission_level = "CAN_RUN"
}
access_control {
group_name = databricks_group.eng.display_name
permission_level = "CAN_EDIT"
}
}By default on AWS deployments, all admin users can sign in to Databricks using either SSO or their username and password, and all API users can authenticate to the Databricks REST APIs using their username and password. As an admin, you can limit admin users’ and API users’ ability to authenticate with their username and password by configuring CAN_USE permissions using password access control.
resource "databricks_group" "guests" {
display_name = "Guest Users"
}
resource "databricks_permissions" "password_usage" {
authorization = "passwords"
access_control {
group_name = databricks_group.guests.display_name
permission_level = "CAN_USE"
}
}Only possible permission to assign to non-admin group is CAN_USE, where admins CAN_MANAGE all tokens:
resource "databricks_group" "auto" {
display_name = "Automation"
}
resource "databricks_group" "eng" {
display_name = "Engineering"
}
resource "databricks_permissions" "token_usage" {
authorization = "tokens"
access_control {
group_name = databricks_group.auto.display_name
permission_level = "CAN_USE"
}
access_control {
group_name = databricks_group.eng.display_name
permission_level = "CAN_USE"
}
}Instance Profiles are not managed by General Permissions API and therefore databricks_group_instance_profile and databricks_user_instance_profile should be used to allow usage of specific AWS EC2 IAM roles to users or groups.
One can control access to databricks_secret through initial_manage_principal argument on databricks_secret_scope or databricks_secret_acl, so that users (or service principals) can READ, WRITE or MANAGE entries within secret scope.
General Permissions API does not apply to access control for tables and permissions have to be managed separately. Though, terraform integration is coming in the future versions.
Exactly one of the following attributes is required:
cluster_id- cluster idjob_id- job iddirectory_id- directory iddirectory_path- path of directorynotebook_id- ID of notebook within workspacenotebook_path- path of notebookcluster_policy_id- cluster policy idinstance_pool_id- instance pool idauthorization- eithertokensorpasswords.
One or more access_control blocks are required to actually set the permission levels:
access_control {
group_name = databricks_group.datascience.display_name
permission_level = "CAN_USE"
}Attributes are:
permission_level- (Required) permission level according to specific resource. See examples above for the reference.user_name- (Optional) name of the user, which should be used if group name is not usedgroup_name- (Optional) name of the group, which should be used if the user name is not used. We recommend setting permissions on groups.
In addition to all arguments above, the following attributes are exported:
id- Canonical unique identifier for the permissions.object_type- type of permissions.
The resource permissions can be imported using the object id
$ terraform import databricks_permissions.this /<object type>/<object id>