avoid azapi

[davidkarlsen]

Isn't the data-plane roles tied to the ARM api anyways? So that instead of using azapi to create container, one could use https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/storage_container ?

[kewalaka]

the create container acts as a control plane operation in the REST API, but the Terraform azurerm equivalent appears to make use of the shared keys (if they are enabled), or otherwise requires a data plane RBAC applied.

it is an odd behavioural difference between the two, which probably should be raised as a bug, if it isn't already.

Happy to be shown an example where this isn't the case (noting the point regarding the shared keys), but this is my experience, and I believe I did try without azapi first this time around as well (but, happy if you wanted to take that example and confirm...)

[davidkarlsen]

It would be nice to see an example - also note that it takes some time from a RBAC assignment until the role takes effect due to eventual consistency. AFAIR we've been able to do this in the past, but I can double check.

[kewalaka]

hi @davidkarlsen - here is a related bug that illustrates the difference between azurerm & azapi.

hashicorp/terraform-provider-azurerm#2977

The key thing that many miss is this setting in their provider block:

provider "azurerm" {
  features {}
  # this setting switches Terraform from using Shared Key Authentication to using Entra ID
  storage_use_azuread        = true
}

Missing this step is a common oversight I see, especially with storage containers used for terraform state - I see "least privileges" on the data plane (e.g. Storage Blob Data Contributor), not realising that under the hood Terraform is just using the shared keys :).

Shared Key authorisation is disabled by default in this resource (as per AVM specs which require aligning to WAF principles), this behaviour can be overridden by setting the shared_access_key_enabled variable.

• WAF guidance: "Avoid and prevent using Shared Key authorization to access storage accounts.", ref:
  https://learn.microsoft.com/en-us/azure/well-architected/service-guides/storage-accounts/security#configuration-recommendations

It's worth noting there are some limitations when disabling Shared Key authorisation, e.g. when using the table & files API as per the AzureRM provider documentation, however this approach works well for things like Terraform state (or any blob workload).

If you wanted to try it our yourself, you could simply take the default example and try create a storage container using the azurerm resource, i.e. something like this:

resource "azurerm_storage_container" "this" {
  name                 = module.naming.storage_container.name_unique
  storage_account_name = module.storage_account.resource.name
}

Hope that's useful & answers this question.

[kewalaka]

@davidkarlsen, so, curiosity got the better of me:

https://github.com/kewalaka/terraform-storagecontainer-sharedkeys

closing on the basis of this output, which shows the behaviour conclusively.