azurerm_builtin_role_definition Incorrectly destroys and creates a role assignment (forces new resource) instead of noop.

[asubmani]

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

v.0.11.7

Affected Resource(s)

• azurerm_role_assignment

Terraform Configuration Files

main.tf

resource "azurerm_resource_group" "aks-kubedev-shared-rg" {
  name     = "aks-kubedev-shared-rg"
  location = "westus"
}
data "azurerm_builtin_role_definition" "ManiOwner" {
  name = "Owner"
}

resource "azurerm_role_assignment" "aks-Owner" {
  scope              = "${azurerm_resource_group.aks-kubedev-shared-rg.id}"
 # role_definition_name = "Owner" 
  role_definition_id = "${data.azurerm_builtin_role_definition.ManiOwner.id}" 
  principal_id       = "a9eae191-1c79-4341-a5bc-321a4c124db6"
}

Debug Output

Panic Output

Expected Behavior

terraform plan should do a noop right after a terraform apply (i.e config ==state==reality)

Actual Behavior

terraform plan does a (forces new resource) with:
Plan: 1 to add, 0 to change and 1 to destroy.

The issue occurs only while using role_definition_id i.e.

${data.azurerm_builtin_role_definition<name>.id}

terraform apply destroys the role assignment and then adds it again.

Steps to Reproduce

1. terraform plan
2. terraform apply
3. terraform plan

Important Factoids

uncomment the line role_definition_name = "Owner" and comment out the line with:
role_definition_id = "${data.azurerm_builtin_role_definition.ManiOwner.id}"
and the issue does not affect if one uses role_definition_name

References

azurerm_builtin_role_definition

• #0000

[srusru]

Hello,

i had faced similar issue. Instead of using role_definition_id, i used role_definition_name and it did work fine. please try that solution. Thanks.

[asubmani]

@reddyed > Yes, I am aware of the workaround. I opened the bug as my customer has a lot of code with role_definition_id in them. Not a biggie but opened the bug in case others are affected by it too.

[donaldguy]

To clarify this bug,

When you fetch the .id from an azurerm_builtin_role_definition it reads as e.g. /providers/Microsoft.Authorization/roleDefinitions/8e3af657-a8ff-443c-a75c-2fe8c4bcb635

this passed to role_definition_id of an azurerm_role_assignment is sufficient to create the role assignment, however on the following refresh, the role_definition_id set on the resource in state is prepended by subscription so e.g /subscriptions/9a2dc252-1ff9-4a0b-8652-6de2cebaef3f/providers/Microsoft.Authorization/roleDefinitions/8e3af657-a8ff-443c-a75c-2fe8c4bcb635

which generates a plan like

-/+ azurerm_role_assignment.aks-Owner (new resource required)
      id:                 "/subscriptions/9a2dc252-1ff9-4a0b-8652-6de2cebaef3f/providers/Microsoft.Authorization/roleAssignments/bcb1b09e-4b07-957c-b36b-e75534eef60f" => <computed> (forces new resource)
      name:               "bcb1b09e-4b07-957c-b36b-e75534eef60f" => <computed>
      principal_id:       "a9eae191-1c79-4341-a5bc-321a4c124db6" => "a9eae191-1c79-4341-a5bc-321a4c124db6"
      role_definition_id: "/subscriptions/9a2dc252-1ff9-4a0b-8652-6de2cebaef3f/providers/Microsoft.Authorization/roleDefinitions/8e3af657-a8ff-443c-a75c-2fe8c4bcb635" => "/providers/Microsoft.Authorization/roleDefinitions/8e3af657-a8ff-443c-a75c-2fe8c4bcb635" (forces new resource)
      scope:              "/subscriptions/9a2dc252-1ff9-4a0b-8652-6de2cebaef3f" => "/subscriptions/9a2dc252-1ff9-4a0b-8652-6de2cebaef3f"

You can work around this, less than ideally, like

data "azurerm_client_config" "current" {}

locals {
  subscription_id = "${data.azurerm_client_config.current.subscription_id}"
}

resource "azurerm_role_assignment" "aks-Owner" {
  scope              = "${azurerm_resource_group.aks-kubedev-shared-rg.id}"
  #NOTE: No slash '/' between the two vars as the one returned by azurerm_builtin_role_definition has a leading slash
  role_definition_id = "/subscriptions/${local.subscription_id}${data.azurerm_builtin_role_definition.ManiOwner.id}" 
  principal_id       = "a9eae191-1c79-4341-a5bc-321a4c124db6"
}

this is similar to the issue reported in #1972

[boillodmanuel]

I suggest the same workaround here: #4847 (comment)

[favoretti]

Since #4847 has a more recent version of provider the issue is reported against and a more active discussion, I'm going to close this issue to keep the topic condensed to one issue. Any feedback/suggestions can be kept in #4847. Thank you.

[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.