Storage container ID inconsistent/incorrect

[debisyw]

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: 0.12.8
AzureRM Provider: 1.33.1

Affected Resource(s)

• azurerm_storage_container

Terraform Configuration Files

Example only

resource "azurerm_storage_container" "container" {
  name                 = "my-container"
  storage_account_name = "example"
}

resource "azurerm_role_assignment" "contributor" {
  scope                = "${azurerm_storage_container.container.id}"
  role_definition_name = "Storage Blob Data Contributor"
  principal_id         = "${data.azuread_service_principal.vm.principal_id}"
}

Expected Behavior

The principal is granted contributor rights to the storage container (not the storage account).

Actual Behavior

The URL of the container is entered into the scope field instead of the correct scope of

/subscriptions/...(redacted).../resourceGroups/my-rg/providers/Microsoft.Storage/storageAccounts/example/blobServices/default/containers/my-container

This is inconsistent with the formatting of the ID attribute on other resources.

Example output plan:

+ resource "azurerm_role_assignment" "contributor" {
      + id                   = (known after apply)
      + name                 = (known after apply)
      + principal_id         = "(redacted)"
      + role_definition_id   = (known after apply)
      + role_definition_name = "Storage Blob Data Reader"
      + scope                = "https://example.blob.core.windows.net/my-container"
    }

[tombuildsstuff]

hi @debisyw

Thanks for opening this issue.

The Storage Container resource is provisioned using the Storage Data Plane API rather than the Resource Manager API which most other resources use; as such the ID for this resource is intentionally using the ID required to access this in the Data Plane API.

Whilst it's now possible to access Storage Containers via the Resource Manager API - unfortunately this only works when using Azure AD for authentication to Storage Accounts (which is being tracked in #3651) however it appears that Azure AD Authentication only works for certain kinds of Storage Resources (and in particular, accounts with "Contributor" roles to the subscription don't automatically have the associated "Storage" permissions, which has confused users when we attempted to switch to this previously) - as such at this time I'm not sure how feasible switching over to those new API's is in the short-term.

The information needed to build up the Resource Manager ID isn't currently available through the Data Plane API - as such whilst it might be possible to rectify this in the future as part of some larger changes (for example by switching this resource to use the storage_account_id rather than the storage_account_name - which I've opened #4442 to track); unfortunately this isn't something we plan to expose in the short-term; as such I'm going to close this issue for the moment in favour of #4442.

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 👉 [email protected]. Thanks!