[ISSUE] `databricks_permission_assignment` doesn't admit empty `permissions`

[camilo-s]

Configuration

terraform {
  required_providers {
    databricks = {
      configuration_aliases = [databricks.account, databricks.default]
      source                = "databricks/databricks"
    }
  }
}

data "databricks_group" "admin" {
  display_name = var.group_name

  provider = databricks.account
}

resource "databricks_permission_assignment" "this" {
  principal_id = data.databricks_group.admin.id
  permissions  = []

  provider = databricks.default
}

resource "databricks_entitlements" "this" {
  group_id              = data.databricks_group.admin.id
  workspace_access      = false
  databricks_sql_access = true

  depends_on = [databricks_permission_assignment.this]
  provider   = databricks.default
}

Expected Behavior

The group is assigned to the workspace (without entitlements), and the group's fine grained entitlements are created further downstream with databricks_entitlements.

Actual Behavior

terraform apply fails with the following error:

│ Error: cannot read permission assignment: <REDACTED> not found
│ 
│   with module.databricks_permission_assignment.databricks_permission_assignment.this,
│   on ../../modules/databricks-permission-assignment/main.tf line 16, in resource "databricks_permission_assignment" "this":
│   16: resource "databricks_permission_assignment" "this" {

Steps to Reproduce

1. Provide input variables
2. terraform apply

Terraform and provider versions

Terraform version: 1.8.3 terraform-provider-databricks_v1.44.0

Is it a regression?

To my knowledge, no.

Debug Output

See linked gist.

Important Factoids

I was unsure if this should be classified as an issue or a feature request. I opted for issue, since IMHO the provider behaves in an unexpected way.

Currently principal entitlements can be set with at least three different resources:

• databricks_{group/user/service_principal}
• databricks_permission_assignment
• databricks_entitlements

Ideally, they should interplay well with each other. For instance, databricks_group optionally admits entitlements as arguments, setting them to null if not provided, so you can set them downstream via databricks_entitlements.

In contrast, by assigning a principal to a workspace with databricks_permission_assignment, you are forced by the provider to assign either "USER" or "ADMIN" for permissions, which carry few workspace entitlements along, leaving you unable to define more fine graded entitlements with databricks_entitlements.

Two use-cases why such behaviour would be reasonable:

• Your BI consumers exist in a Databricks account group. You want to assign the group to a workspace in such a way that they have databricks_sql_access but no workspace_access.
• You need to enable a group of workspace admins to manage account groups from the workspace admin settings, without giving them access to the Databricks account console. For this, you could assign the groups to be managed to a workspace without entitlements, and then the workspace admins can add or remove members from these groups as needed.

Another reason why the behavior is unexpected: the (account-level) Permission Assignment API admits doing assignments with empty permissions. Granted, I believe the Terraform resource databricks_permission_assignment uses a different API, but it would be just intuitive to expect it to work analogously.

Would you like to implement a fix?

With some guidance yes.