azurerm_role_assignment fails due to use of deprecated 2018-01-01-preview api

[CoaxVex]

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 v0.13.5

• provider registry.terraform.io/-/azuread v1.1.1
• provider registry.terraform.io/-/azurerm v2.38.0
• provider registry.terraform.io/-/random v3.0.0
• provider registry.terraform.io/hashicorp/azuread v1.1.1
• provider registry.terraform.io/hashicorp/azurerm v2.38.0
• provider registry.terraform.io/hashicorp/random v3.0.0

Affected Resource(s)

• azurerm_role_assignment

Terraform Configuration Files

resource "azurerm_role_assignment" "agic-contributor" {
  role_definition_name = "Contributor"
  scope                = "${data.azurerm_subscription.current.id}/resourceGroups/${azurerm_resource_group.publicportal.id}"
  principal_id         = azuread_service_principal.agic.id
}

Panic Output

Error: Error loading Role Definition List: authorization.RoleDefinitionsClient#List: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="InvalidApiVersionParameter" Message="The api-version '2018-01-01-preview' is invalid. The supported versions are '2020-10-01,2020-09-01,2020-08-01,2020-07-01,2020-06-01,2020-05-01,2020-01-01,2019-11-01,2019-10-01,2019-09-01,2019-08-01,2019-07-01,2019-06-01,2019-05-10,2019-05-01,2019-03-01,2018-11-01,2018-09-01,2018-08-01,2018-07-01,2018-06-01,2018-05-01,2018-02-01,2018-01-01,2017-12-01,2017-08-01,2017-06-01,2017-05-10,2017-05-01,2017-03-01,2016-09-01,2016-07-01,2016-06-01,2016-02-01,2015-11-01,2015-01-01,2014-04-01-preview,2014-04-01,2014-01-01,2013-03-01,2014-02-26,2014-04'."

  on main.tf line 186, in resource "azurerm_role_assignment" "agic-contributor":
 186: resource "azurerm_role_assignment" "agic-contributor" {

Expected Behaviour

Create role assignment

Actual Behaviour

See Panic Output.

Steps to Reproduce

1. terraform apply

Important Factoids

References

[philbal611]

Not sure if you've resolved this already @CoaxVex, but it appears the scope is a bit off here. Looks like you're concatenating "${data.azurerm_subscription.current.id}/resourceGroups/" with the full RG ID ${azurerm_resource_group.publicportal.id}, instead of the name. Alternatively, if you have the RG reference, you can just use azurerm_resource_group.publicportal.id as the scope value.

I ran into the exact same error with a syntactically incorrect scope for this resource. Responding to provide a solution to others who may run into this unhelpful error.

[tombuildsstuff]

hi @CoaxVex

Thanks for opening this issue / apologies for the delayed response here!

As @philbal611 has mentioned, unfortunately these errors come from the Azure API, where different versions of the API are available at /subscriptions/{id}, /subscriptions/{id}/resourceGroups/{name} and /subscriptions/{id}/resourceGroups/{name}/providers/{name}/{thing}/{name}. Since the scope in this instance is used as the prefix for the role assignment, unfortunately passing an incorrect scope can return this misleading error, since the API believes that your trying to access a different API than you are, due to the incorrect scope/prefix.

To your question regarding the 2018-01-01-preview API, a few weeks ago I'd opened this issue against the Azure API requesting a clarification, since there's been no stable release of the Authorization API (used for Role Assignments) in ~4 years - unfortunately that's still waiting for the Service Team to respond.

Since this should be fixed by updating the Terraform Configuration being used here, as @philbal611 has suggested - I'm going to close this issue for the moment. I'm going to open a separate PR to add validation to the scope too, since we should be able to validate this is a Management Group, Subscription, Resource Group or otherwise a Resource ID - which should help (somewhat) in the future.

Thanks!

[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 👉 hashibot-feedback@hashicorp.com. Thanks!