azurerm_role_assignment falsely detects drift in the role_definition_id property due to incorrectly setting/calculating the property during plan

[GraemeMeyerGT]

Community Note

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

Terraform (and AzureAD Provider) Version

We're using the hashicorp/setup-terraform@v2 action in GitHub Actions, which doesn't seem to actually print/provide the Terraform version used, but I assume it's the latest version or closest ~LTS equivalent.

This is azuread provider 3.1.0

    azuread = {
      source = "hashicorp/azuread"
      version = "3.1.0"
    }

Affected Resource(s)

• azurerm_role_assignment
• azurerm_role_definition

Terraform Configuration Files

The Terraform snippet is like this. The AAD/Entra group "VM Administrators" already exists and the principal has access to it.

data "azurerm_role_definition" "vm-administrators" {
  name = "Virtual Machine Administrator Login"
}

resource "azurerm_role_assignment" "vm-administrator-login" {
  scope              = azurerm_linux_virtual_machine.this.id
  role_definition_id = data.azurerm_role_definition.vm-administrators.id
  principal_id       = data.azuread_group.vm-administrators.object_id
}

data "azuread_group" "vm-administrators" {
  display_name = "VM Administrators"  
}

Panic/Debug Output

Terraform will perform the following actions:
  # azurerm_role_assignment.vm-administrator-login must be replaced
-/+ resource "azurerm_role_assignment" "vm-administrator-login" {
      ~ id                                     = "/subscriptions/1234567890-my-subscription-id-0987654321/resourceGroups/My-Virtual-Machine-rg/providers/Microsoft.Compute/virtualMachines/My-Virtual-Machine-vm/providers/Microsoft.Authorization/roleAssignments/8eb0a8be-5171-0aa8-52fa-6f42104da9eb" -> (known after apply)
      ~ name                                   = "8eb0a8be-5171-0aa8-52fa-6f42104da9eb" -> (known after apply)
      ~ principal_type                         = "Group" -> (known after apply)
      ~ role_definition_id                     = "/subscriptions/1234567890-my-subscription-id-0987654321/providers/Microsoft.Authorization/roleDefinitions/1c0163c0-47e6-4577-8991-ea5c82e286e4" -> "/providers/Microsoft.Authorization/roleDefinitions/1c0163c0-47e6-4577-8991-ea5c82e286e4" # forces replacement
      ~ role_definition_name                   = "Virtual Machine Administrator Login" -> (known after apply)
      + skip_service_principal_aad_check       = (known after apply)
        # (6 unchanged attributes hidden)
    }
Plan: 1 to add, 0 to change, 1 to destroy.

Expected Behavior

The plan stage shouldn't detect any difference between the infrastructure and the configuration and shouldn't proceed to an apply stage.

Actual Behavior

Every time you run Terraform plan-apply, the same configuration drift is detected. The property difference is always:

~ role_definition_id                     = "/subscriptions/1234567890-my-subscription-id-0987654321/providers/Microsoft.Authorization/roleDefinitions/1c0163c0-47e6-4577-8991-ea5c82e286e4" -> "/providers/Microsoft.Authorization/roleDefinitions/1c0163c0-47e6-4577-8991-ea5c82e286e4" # forces replacement

It seems that Terraform is always constructing the role_definition_id property as /providers/Microsoft.Authorization/roleDefinitions/..., but then either Terraform or Azure is setting the role_definition_id property to /subscriptions/1234567890-my-subscription-id-0987654321/providers/Microsoft.Authorization/roleDefinitions/..., and thus the next time around Terraform detects this as a drift.

I have checked the state file for my data.azurerm_role_definition, and both the id and role_definition_id properties are stored as /providers/... - i.e. "incorrect", from the point of view of this scenario. I'm not a Terraform wiz, so I'm not sure which, but I'm pretty sure at least one of the properties on azurerm_role_definition should be directly accessible with the correct ID format. I'm thus not entirely sure whether the bug would be with the azurerm_role_assignment resource, or the azurerm_role_definition data source.

Steps to Reproduce

1. Create an AAD group in Azure portal manually.
2. Use the data.azuread_group resource to fetch it's properties.
3. Try to assign the built-in Virtual Machine Administrator Login role to the group, with scope of a virtual machine (I used azurerm_linux_virtual_machine).
4. Run Terraform plan-apply several times to demonstrate the repeating issue.

Important Factoids

This is how I've ended up working around the issue for now - building a role_definition_id string manually so that the provider doesn't incorrectly detect drift during the plan stage:

data "azurerm_role_definition" "vm-administrators" {
  name = "Virtual Machine Administrator Login"
}

resource "azurerm_role_assignment" "vm-administrator-login" {
  scope              = azurerm_linux_virtual_machine.this.id
  role_definition_id = "/subscriptions/${data.azurerm_client_config.current.subscription_id}${data.azurerm_role_definition.vm-administrators.role_definition_id}"
  principal_id       = data.azuread_group.vm-administrators.object_id
}

data "azuread_group" "vm-administrators" {
  display_name = "VM Administrators"  
}

This works well, and Terraform no-longer detects drift.

[GraemeMeyerGT]

Oops closing issue for now as this may be related to the azurearm provider. Will review and re-open if necessary.