azurerm_storage_container.NAME.id returns an unpathed resource ID

[Supermathie]

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

Terraform v0.11.7

• provider.azurerm v1.9.0
• provider.random v1.3.1

Affected Resource(s)

• azurerm_storage_container

Terraform Configuration Files

resource "azurerm_storage_container" "assets" {
  name                  = "assets"
  resource_group_name   = "${azurerm_resource_group.app.name}"
  storage_account_name  = "${azurerm_storage_account.app.name}"
  container_access_type = "blob" # anon read for blobs
}

resource "azurerm_role_assignment" "role_assignment" {
  scope                = "${azurerm_storage_container.assets.id}"
  role_definition_id   = "${azurerm_role_definition.blob_contributor.id}"
  principal_id         = "${local.principal_id}"

  lifecycle {
    ignore_changes = ["name"]
  }
}

Debug Output

(available on request)

Panic Output

Expected Behavior

azurerm_storage_container.NAME.id should return a complete path to the resource ID

Actual Behavior

azurerm_storage_container.NAME.id returns only the storage container name:

Terraform will perform the following actions:

  + azurerm_role_assignment.role_assignment
      id:                 <computed>
      name:               <computed>
      principal_id:       "c0824800-21a1-471a-8863-xxxx"
      role_definition_id: "/subscriptions/16b9f5dc-3276-4b32-91b2-xxxx/providers/Microsoft.Authorization/roleDefinitions/29b53033-c386-ba60-e9c0-xxxx"
      scope:              "assets"

Steps to Reproduce

1. terraform apply

Important Factoids

Ø

References

Ø

[tombuildsstuff]

hi @Supermathie

Thanks for opening this issue :)

The ID of the Storage Container matches the name since this is the identifier used to access it within Azure; there's no fully scoped path that I'm aware of (technically the Container name is used internally within the SDK to populate [scheme]://[account].[domain]/container] - but this cannot be used for resource scoping as far as I'm aware). Would you be able to give an example of the identifier you're looking for here?

As far as I'm aware roles can only be scoped to full resources in Azure, rather than components of resources (e.g. to a Storage Account rather a Storage Container). Would you be able to take a look and see if scoping to the Storage Account works for you?

Thanks!

[Supermathie]

I wasn't 100% sure but I figured since EVERY OTHER resource (I've found) returns the fully qualified path from the id method, this one should as well.

Would you be able to take a look and see if scoping to the Storage Account works for you?

It works but isn't useful, but that's because #1538 needs to be added first before I can actually add anything to the container.

(I can't use role_definition_name = "Storage Blob Data Contributor (Preview)" because Preview roles are not supported)

As far as I'm aware roles can only be scoped to full resources in Azure

According to the docs:

The scope can be any REST resource instance.

so I just tried adding the builtin Contributor via the GUI and it worked!

Listing the new assignments via az role assignment list --all shows:

  {
    "additionalProperties": {},
    "canDelegate": null,
    "id": "/subscriptions/16b9f5dc-3276-4b32-91b2-xxxx/resourceGroups/xxxx-dev-michael-meta/providers/Microsoft.Storage/storageAccounts/xxxxdevmichaelmeta/blobServices/default/containers/assets/providers/Microsoft.Authorization/roleAssignments/0001d545-32b1-4886-8386-69f9b6382148",
    "name": "0001d545-32b1-4886-8386-69f9b6382148",
    "principalId": "85967648-3a1c-45c0-b14b-df1fb045ecf3",
    "principalName": "27576c5d-8b57-4d48-9a14-c783aff59d29",
    "resourceGroup": "xxxx-dev-michael-meta",
    "roleDefinitionId": "/subscriptions/16b9f5dc-3276-4b32-91b2-xxxx/providers/Microsoft.Authorization/roleDefinitions/ba92f5b4-2d11-453d-a403-e96b0029c9fe",
    "roleDefinitionName": "Storage Blob Data Contributor (Preview)",
    "scope": "/subscriptions/16b9f5dc-3276-4b32-91b2-xxxx/resourceGroups/xxxx-dev-michael-meta/providers/Microsoft.Storage/storageAccounts/xxxxdevmichaelmeta/blobServices/default/containers/assets",
    "type": "Microsoft.Authorization/roleAssignments"
  },

That actually helps - it means that the role assignment works with a scope line of:

  scope                = "${azurerm_storage_account.app.id}/blobServices/default/containers/${azurerm_storage_container.assets.id}"

… which is not very intuitive …

Given all of the above I propose that the full string:

"${azurerm_storage_account.app.id}/blobServices/default/containers/${azurerm_storage_container.assets.name}"

would be a good candidate for azurerm_storage_container.assets.id (because at the moment the id is the same as name?

That would mean that the very intuitive:

resource "azurerm_role_assignment" "role_assignment" {
  scope                = "${azurerm_storage_container.test.id}"
  …
}

works!

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