Why does the azurerm backend not support `storage_use_azuread`?

Terraform Providers Azure
1

I suspect this is not a bug, therefore I am writing to this forum.

The azurerm terraform provider is able to use Azure RBAC to read/write within Azure Storage (blobs/queues, to be precise). This is achieved by either adding the configuration attribute storage_use_azuread to the provider configuration or by using the ARM_STORAGE_USE_AZUREAD environment variable.

However, the azurerm terraform backend does not support RBAC and always attempts to use the storage account key. Is there a reason for this? Given the type of data that is stored by terraform itself I would expect it to be much more important to have RBAC for the backend rather than random storage accounts created as IaC.

P. S. I tested with the environment variable and by setting the undocumented storage_use_azuread attribute on the backend config, but, as expected, the backend has no support for this and continues trying to use the key instead.
This results in an (expected) error message:
Error: Failed to get existing workspaces: containers.Client#ListBlobs: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="KeyBasedAuthenticationNotPermitted" Message="Key based authentication is not permitted on this storage account.

The service principal in use has the “Storage Blob Data Contributor” role set at the scope of the Storage Account. I can use that service principal via Azure CLI with --auth-mode login to upload/download blobs successfully.

2 Likes
2

Just ran into the same issue
Looking forward for an update

3

A workaround is to use a User Delegation SAS in conjunction with sas_token azurerm backend authentication
(Backend Type: azurerm - Terraform by HashiCorp)

1 Like
4

I have looked into this, it is a valid workaround, thanks!
However, the feature parity issue between provider and backend still stands. I wonder if I should report this as a bug just to get someone who isn’t a user to take a look at this.

For the reference to anyone that has this issue, here’s a link to Azure documentation for the object ID based SAS and its generation:

5

Try the backend config option use_azuread_auth=true in the backend config block instead. I was able to get this to work using only MSI and no stored credentials.

1 Like
6

not sure how you were able to do this. it’s not working for me.
I have both Storage Blob Owner and Contributor to my azure ad account and I’m also able to access the container and blob with Azure Storage Explorer.

My provider looks like this:

terraform {
backend “azurerm” {
resource_group_name = “tools-mgmt”
storage_account_name = “*********”
container_name = “terraform-tfstate”
key = “prod-tools-mgmt.tfstate”
use_azuread_auth = true
}
required_providers
azurerm = {
source = “hashicorp/azurerm”
}
}
}

the storage account already exists, but when I do the flip with
shared_access_key_enabled from true to false, it doesn’t work anymore

resource “azurerm_storage_account” “sa” {
name = “sa${var.environment}${var.subscription_shortname}tf”
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
account_tier = “Standard”
account_replication_type = “GRS”
min_tls_version = “TLS1_2”
shared_access_key_enabled = false

I just get the regular:

Error: reading queue properties for AzureRM Storage Account “*******”: queues.Client#GetServiceProperties: Failure responding to request: StatusCode=403 – Original Error: autorest/azure: Service returned an error. Status=403 Code=“KeyBasedAuthenticationNotPermitted” Message=“Key based authentication is not permitted on this storage account.\nRequestId:af1b1441-e003-0054-4c65-bc0a26000000\nTime:2021-10-08T16:54:44.2038418Z”

7

My backend config also has use_msi = true in it, try that