azurerm_role_assignment replaces unchanged role assignment

[DevopsMercenary]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

1.3.6

AzureRM Provider Version

3.37.0

Affected Resource(s)/Data Source(s)

azurerm_role_assignment

Terraform Configuration Files

resource "azurerm_resource_group" "default" {

  name     = "expl-anal-avd-vm"
  location = "eastus"
}

data "azurerm_role_definition" "smb-contributor" {
  name = "Storage File Data SMB Share Contributor"
}

data "azuread_group" "virtual-desktop-admin-group" {

  display_name     = "expl-anal-virtual-desktop-admin"

  security_enabled = true
}

resource "azurerm_role_assignment" "smb-contributor" {

  scope              = azurerm_resource_group.default.id

  role_definition_id = data.azurerm_role_definition.smb-contributor.id

  principal_id       = data.azuread_group.virtual-desktop-admin-group.id

}

Debug Output/Panic Output

# azurerm_role_assignment.smb-contributor must be replaced
-/+ resource "azurerm_role_assignment" "smb-contributor" {
      ~ id                               = "/subscriptions/0f849332-18f0-45f6-abf6-3bcd9058d3eb/resourceGroups/expl-anal-avd-vm/providers/Microsoft.Authorization/roleAssignments/8da43c30-fd6f-3cf3-3efb-7423ec633eb7" -> (known after apply)
      ~ name                             = "8da43c30-fd6f-3cf3-3efb-7423ec633eb7" -> (known after apply)
      ~ principal_type                   = "Group" -> (known after apply)
      ~ role_definition_id               = "/subscriptions/0f849332-18f0-45f6-abf6-3bcd9058d3eb/providers/Microsoft.Authorization/roleDefinitions/0c867c2a-1d8c-454a-a3db-ab2ea1bdc8bb" -> "/providers/Microsoft.Authorization/roleDefinitions/0c867c2a-1d8c-454a-a3db-ab2ea1bdc8bb" # forces replacement
      ~ role_definition_name             = "Storage File Data SMB Share Contributor" -> (known after apply)
      + skip_service_principal_aad_check = (known after apply)
        # (2 unchanged attributes hidden)
    }

Expected Behaviour

I wouldn't expect the assignment to change just because the strings don't match exactly and one is just a substring of the other.

Actual Behaviour

The role assignment is needlessly replaced

Steps to Reproduce

terraform apply

Important Factoids

none

References

not that I know of

[liuwuliuyun]

Hi @DevopsMercenary , thanks for raising this issue. I could see the plan is not empty and showing force replacement. Does this happen when you first run terraform apply then rerun terraform plan or apply?

[DevopsMercenary]

I only ever run `terraform apply`. I’ve never tried it with a plan first. - Gregory BonkOn Jan 3, 2023, at 10:59 PM, Yun Liu ***@***.***> wrote: Hi @DevopsMercenary , thanks for raising this issue. I could see the plan is not empty and showing force replacement. Does this happen when you first run terraform apply then rerun terraform plan or apply? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[liuwuliuyun]

So this happens when you first run terraform apply? That is weird, force replacement usually happens when you changing an exsiting resource, but when running terraform apply for the first time, there should be no resource already exists.

[DevopsMercenary]

No, sorry. Only happens after the resource has been created. First terraform apply is fine, all subsequent terraform apply result in the now existing resource being unnecessarily replaced.

[alxy]

It looks like data.azurerm_role_definition.smb-contributor.id returns the role id without the subscription prefix, which makes terraform try to do an update:

/subscriptions/0f849332-18f0-45f6-abf6-3bcd9058d3eb/providers/Microsoft.Authorization/roleDefinitions/0c867c2a-1d8c-454a-a3db-ab2ea1bdc8bb

vs

/providers/Microsoft.Authorization/roleDefinitions/0c867c2a-1d8c-454a-a3db-ab2ea1bdc8bb

Not sure if that is a bug, but can you try to modify your code like this and see if the update goes away?

data "azurerm_subscription" "primary" {
}

data "azurerm_role_definition" "smb-contributor" {
  name = "Storage File Data SMB Share Contributor"
  scope  = data.azurerm_subscription.primary.id # /subscriptions/00000000-0000-0000-0000-000000000000
}

# ...

[liuwuliuyun]

Another way to solve this is using role_definition_id = "${data.azurerm_subscription.primary.id}${data.azurerm_role_definition.test.id}" to include subscription id. I think this will solve your problem.

[DevopsMercenary]

scope  = data.azurerm_subscription.primary.id

Gave this a shot. Terraform still planned for replacement....

Code Update

data "azurerm_subscription" "primary" {
}

resource "azurerm_role_assignment" "storage-role" {

  scope              = data.azurerm_subscription.primary.id

  role_definition_id = data.azurerm_role_definition.storage-role.id

  principal_id       = data.azuread_group.aad-group.object_id
}

Terraform's Replacement Plan

  # azurerm_role_assignment.storage-role must be replaced
-/+ resource "azurerm_role_assignment" "storage-role" {
      ~ id                               = "/subscriptions/0f849332-18f0-45f6-abf6-3bcd9058d3eb/resourceGroups/virtual-desktop-storage/providers/Microsoft.Storage/storageAccounts/avddesktopekj4/providers/Microsoft.Authorization/roleAssignments/a3fb7639-127a-9f6c-9c21-587b097f2b3a" -> (known after apply)
      ~ name                             = "a3fb7639-127a-9f6c-9c21-587b097f2b3a" -> (known after apply)
      ~ principal_type                   = "Group" -> (known after apply)
      ~ role_definition_id               = "/subscriptions/0f849332-18f0-45f6-abf6-3bcd9058d3eb/providers/Microsoft.Authorization/roleDefinitions/0c867c2a-1d8c-454a-a3db-ab2ea1bdc8bb" -> "/providers/Microsoft.Authorization/roleDefinitions/0c867c2a-1d8c-454a-a3db-ab2ea1bdc8bb" # forces replacement
      ~ role_definition_name             = "Storage File Data SMB Share Contributor" -> (known after apply)
      ~ scope                            = "/subscriptions/0f849332-18f0-45f6-abf6-3bcd9058d3eb/resourceGroups/virtual-desktop-storage/providers/Microsoft.Storage/storageAccounts/avddesktopekj4" -> "/subscriptions/0f849332-18f0-45f6-abf6-3bcd9058d3eb" # forces replacement
      + skip_service_principal_aad_check = (known after apply)
        # (1 unchanged attribute hidden)
    }

[DevopsMercenary]

data "azurerm_subscription" "primary" {
}

data "azurerm_role_definition" "smb-contributor" {
  name = "Storage File Data SMB Share Contributor"
  scope  = data.azurerm_subscription.primary.id # /subscriptions/00000000-0000-0000-0000-000000000000
}

Sorry. Did that wrong. This does work. My Code change.

ata "azurerm_subscription" "primary" {
}

data "azurerm_role_definition" "storage-role" {
  name = "Storage File Data SMB Share Contributor"
  scope  = data.azurerm_subscription.primary.id # /subscriptions/00000000-0000-0000-0000-000000000000
}


resource "azurerm_role_assignment" "storage-role" {

  scope              = azurerm_storage_account.storage.id

  role_definition_id = data.azurerm_role_definition.storage-role.id

  principal_id       = data.azuread_group.aad-group.object_id
}

[DevopsMercenary]

Another way to solve this is using role_definition_id = "${data.azurerm_subscription.primary.id}${data.azurerm_role_definition.test.id}" to include subscription id. I think this will solve your problem.

Yes. That does work.

[DevopsMercenary]

Great. A couple of options here. Any preference? Not a 'bug' ?

[liuwuliuyun]

Yeah, this is not a bug, even in the build-in test cases in this project, role_definition_id is written as role_definition_id = "${data.azurerm_subscription.primary.id}${data.azurerm_role_definition.test.id}". But I think both ways are acceptable and I dont have any preference here.

[manicminer]

@liuwuliuyun Thanks for your help with this issue.

@DevopsMercenary As this has been determined to not be a bug, I'm going to close this issue for now. If I have misunderstood and there is a bug to fix in the provider, please feel free to reply and we'll happily take another look.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.