azurerm_role_assignment will be recreated right after importing

[gevial]

Is there an existing issue for this?

• [X] I have searched the existing issues

Community Note

• Please vote on this issue by adding a :thumbsup: 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

v1.1.7

AzureRM Provider Version

3.0.2

Affected Resource(s)/Data Source(s)

azurerm_role_assignment

Terraform Configuration Files

resource "azurerm_role_assignment" "developers" {
  scope                = azurerm_kubernetes_cluster.sandbox.id
  role_definition_name = data.azurerm_role_definition.kubernetes_writer.name
  principal_id         = var.developers_group_object_id
}

Debug Output/Panic Output

# azurerm_role_assignment.developers must be replaced
-/+ resource "azurerm_role_assignment" "developers" {
      ~ id                               = "/subscriptions/xxx/resourceGroups/xxx/providers/Microsoft.ContainerService/managedClusters/xxx/providers/Microsoft.Authorization/roleAssignments/xxx" -> (known after apply)
      ~ name                             = "xxx" -> (known after apply)
      ~ principal_type                   = "Group" -> (known after apply)
      ~ role_definition_id               = "/subscriptions/xxx/providers/Microsoft.Authorization/roleDefinitions/xxx" -> (known after apply)
      ~ scope                            = "/subscriptions/xxx/resourcegroups/ttn-s-rg000/providers/Microsoft.ContainerService/managedClusters/xxx" -> "/subscriptions/xxx/resourceGroups/xxx/providers/Microsoft.ContainerService/managedClusters/xxx" # forces replacement
      + skip_service_principal_aad_check = (known after apply)
        # (2 unchanged attributes hidden)

      - timeouts {}
    }

Expected Behaviour

Expected no changes.

Actual Behaviour

Terraform tries to replace the imported role assignment. Doesn't matter if you import it with resourcegroups or resourceGroups in the id, in the state it lands with all lower case. And later on terraform plan will try to replace the assignment with resourceGroups (capital G) in the id.

Steps to Reproduce

1. Define azurerm_role_assignment as per the above in the code.
2. Import existing assignment with either

terraform import azurerm_role_assignment.developers /subscriptions/xxx/resourceGroups/xxx/providers/Microsoft.ContainerService/managedClusters/xxx/providers/Microsoft.Authorization/roleAssignments/xxx

OR the same import command but resourcegroups instead of resourceGroups in the id (notice letter G is different).

Terraform plan will show re-create in both ways.

Important Factoids

No response

References

No response

[gevial]

I tried to manually change 'g' to capital in the state but it didn't help. Seems to me like scope id gets normalised by Terraform upon execution.

[myc2h6o]

Hi @gevial Thanks for opening the issue! I'm seeing the same issue when creating a role assignment on Azure Portal. I've then tried below two options which can give the correct indicator resourceGroups you may want to give a try:

1. By using Terraform/Azure CLI/REST API to create the role assignment, the resource group indicator is correct, which is resourceGroups.

2. And to fix it in-place, you can use an update call with the expected scope (with the upper G in resourceGroups) with Azure CLI az role assignment update or REST API PUT request (can be found in the above link). A small note: in my test, it can update resourcegroup to resourceGroup, but not the reverse way.

[MAmmerlaan]

I see the same behavior on the following objects all on v 3.13.0 of the azureRM provider (and Terraform v1.2.4)

• azurerm_monitor_metric_alert
• azurerm_servicebus_topic
• azurerm_servicebus_subscription

[yildizbilal]

For me v3.15.1 azurerm provider and terraform v1.2.4:

• azurerm_kubernetes_cluster_node_pool

For: kubernetes_cluster_id = azurerm_kubernetes_cluster.aks-cluster.id

[dellch]

Would the fix here be similar to #16267 which fixed #16166?