azurerm_role_definition resource id attribute is not valid

[mdgreenfield]

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 (and AzureRM Provider) Version

$ terraform -v
Terraform v0.13.2
+ provider registry.terraform.io/hashicorp/azuread v0.11.0
+ provider registry.terraform.io/hashicorp/azurerm v2.27.0
+ provider registry.terraform.io/hashicorp/template v2.1.2

Affected Resource(s)

• azurerm_role_definition
• azurerm_role_assignment

Terraform Configuration Files

resource azurerm_role_definition custom{
  name = "custom"

  scope = "/subscriptions/${var.subscription}"

  permissions {
    actions = [
      "Microsoft.Authorization/roleDefinitions/*",
      "Microsoft.Authorization/roleAssignments/*",
    ]
  }

  assignable_scopes = ["/subscriptions/${var.subscription}"]
}

resource azurerm_role_assignment custom {
  role_definition_id = azurerm_role_definition.custom.id
  scope              = "/subscriptions/${var.subscription}"
  principal_id       = azuread_service_principal.custom.id
}

Expected Behavior

No error. Role definition can be found by the provider.

Actual Behavior

Error: authorization.RoleAssignmentsClient#Create: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="InvalidRoleDefinitionId" Message="The role definition ID '346221fa-9b2f-2c40-1c8c-45ef50d4f2c9|' is not valid."

It appears as though the id attribute was changed in version 2.27.0 to include the scope as fmt.Sprintf("%s|%s", *existing.ID, scope) (see https://github.com/terraform-providers/terraform-provider-azurerm/blob/master/azurerm/internal/services/authorization/role_definition_resource.go#L156). As a result the azurerm_role_assignment is not able to correctly read the role_definition_id that is passed in.

Steps to Reproduce

1. Configure a custom role definition
2. Configure a role assignment
3. terraform apply

References

This appears to be related to #6107 introduced in 2.27.0 yesterday.

[mdgreenfield]

Note that I was able to work around this with the following aurerm_role_assignment:

resource azurerm_role_assignment custom {
  role_definition_id = trimsuffix(azurerm_role_definition.custom.id, "|${azurerm_role_definition.custom.scope}")
  scope              = "/subscriptions/${var.subscription}"
  principal_id       = azuread_service_principal.custom.id
}

[fgarcia-cnb]

we are seeing this same issue as of this morning (when 2,27 was released). 2.26 of the provider does not have this problem

[derek-burdick]

When using it as a reference in azurerm_role_assignment, it errors out as well.

Trying to import an existing role gives this error:
could not parse Role Definition ID, invalid format "/subscriptions/d5383fc2-ca4d-4363-a262-f4a24f408a76/providers/Microsoft.Authorization/roleDefinitions/d03e9281-e40b-ce94-8e1d-8462bef42567"

Falling back to 2.26.0 solves the issue.

[easimon]

Falling back to 2.26.0 solves the issue.

Except that it does not when you already tried to apply with 2.27 (and other changes were successful).

Error: Resource instance managed by newer provider version
The current state of
...
was created by a newer provider version than is currently selected. Upgrade
the registry.terraform.io/-/azurerm provider to work with this state.

🙄

[cub10s1ty]

This is killing my deployment pipelines everywhere. How quickly can we fix this?!

[derek-burdick]

Falling back to 2.26.0 solves the issue.

Except that it does not when you already tried to apply with 2.27 (and other changes were successful).

Error: Resource instance managed by newer provider version
The current state of
...
was created by a newer provider version than is currently selected. Upgrade
the registry.terraform.io/-/azurerm provider to work with this state.

🙄

I had to run the following for each resource to use the earlier provider.

terraform state rm ...
terraform import ... ...

[derek-burdick]

Can we get this marked as a bug/defect? The resource ID attribute can no longer be used as reference in other objects. This breaks quite a bit of code and is not easy to workaround.

[brandonvin]

In my case, this broke azurerm_role_assignment that was using the ID of azurerm_role_definition resources. As a temporary workaround, I was able to plan/apply by changing to use name attribute instead.

# broken in 2.27 because role definition ID is invalid
resource "azurerm_role_assignment" "foo" {
  ...
  role_definition_id = azurerm_role_definition.foo.id
}

# workaround
resource "azurerm_role_assignment" "foo" {
  ...
  role_definition_name = azurerm_role_definition.foo.name
}

[easimon]

I had to run the following for each resource to use the earlier provider.

terraform state rm ...
terraform import ... ...

I can confirm this works, using the older version for both commands. Also terraform state rm does not try to interpret the incompatible state schema_version. Thanks for the hint.

[restfulhead]

This also broke our deployment. The id now seems to be a tuple of some sort. I was able to recover from this by using the split function when referring to the id:

Before: azurerm_role_definition.my_role_def.id
After: split("|", azurerm_role_definition.my_role_def.id)[0]

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!