[ISSUE] Issue with `databricks_permissions` resource - implicit owner for service principal

[marcin-sg]

I understand that for many resources the provider grants implicit owner (IS_OWNER or CAN_MANAGE) permission. However this is getting problematic when an users wants to generate a plan using a different authentication. In our current setup a deployment pipeline uses an Azure service principle to authenticate to Databricks and create a set of resources: cluster, jobs etc. Developers are allowed to run terraform plan from their environment while authenticating with azure cli. This causes permissions to all resources to be marked as changed. To avoid excessive list of changes, we thought about granting the sp explicitly owner rights. For developers it does work, however this time the deployment pipeline claims changes (which can be safely apply anyhow...)

Configuration

resource "databricks_permissions" "job_permission" {
  job_id = databricks_job.job.id

  access_control {
    permission_level       = "IS_OWNER"
    service_principal_name = var.owner
  }
}

Expected Behavior

No changes. Your infrastructure matches the configuration. Independent on user used to run terraform plan

Actual Behavior

When running using sp credentials - despite the fact it alread has owner permissions

  # job_permission will be updated in-place
  ~ resource "databricks_permissions" "job_permissions" {
        id          = "/jobs/0"
        # (2 unchanged attributes hidden)

      + access_control {
          + permission_level       = "IS_OWNER"
          + service_principal_name = "***"
        }

    }

Steps to Reproduce

1. terraform apply (with sp authentication)
2. terrafrom plan

Terraform and provider versions

Terraform v1.5.0 on linux_amd64

• provider registry.terraform.io/databricks/databricks v1.18.0
• provider registry.terraform.io/hashicorp/azurerm v3.63.0

Debug Output

I guess it is not needed

Important Factoids

Checking the code:

1. Seems that current permissions for the current user are always ignored (link)
2. Implicit permissions are always using user_name (link) - not distinguishing if the current user might be sp - guess the limitations come from Databricks API.

My first thought would be to change point 1 and 2 and explicitly mention in the plan that implicit permissions will be granted or keep in the state information that they have been granted. I guess there are reasons speaking against it.

A bit cumbersome workaround we use now is to, based on a variable, create explicit permissions or not. Any better idea?

resource "databricks_permissions" "cluster_permission" {
  cluster_id = databricks_cluster.cluster.cluster_id

  dynamic "access_control" {
    for_each = var.deployment ? [] : [1]
    content {
      permission_level       = "CAN_MANAGE"
      service_principal_name = var.owner
    }
  }

[AkhilGNair]

Doing the same workaround for the same issue but with

data "databricks_current_user" "me" {}

resource "databricks_permissions" "job_permission" {
   job_id   = databricks_job.jobs[each.key].id

  dynamic "access_control" {
    for_each = data.databricks_current_user.me.user_name == var_owner? [] : [1]
    content {
      permission_level       = "IS_OWNER"
      service_principal_name = var.owner
    }
  }