azurerm_storage_account cannot be created without internet access due to static_website field

[msteiger]

Is there an existing issue for this?

• I have searched the existing issues

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 comments along the lines of "+1", "me too" or "any updates", 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 and review the contribution guide to help.

Terraform Version

1.9.5

AzureRM Provider Version

4.3.0

Affected Resource(s)/Data Source(s)

azurerm_storage_account

Terraform Configuration Files

resource "azurerm_storage_account" "configs" {
  name                     = var.config_storage_name
  resource_group_name      = azurerm_resource_group.stage.name
  location                 = azurerm_resource_group.stage.location
  account_tier             = "Standard"
  account_replication_type = "LRS"

  allow_nested_items_to_be_public = false
  public_network_access_enabled = false

  lifecycle {
    ignore_changes = [static_website]
  }
}

Debug Output/Panic Output

Error: retrieving static website properties for Storage Account (Subscription: "[MASKED]"
│ Resource Group Name: "[MASKED]"
│ Storage Account Name: "configapp52xxxxx"): executing request: Get "https://configapp52xxxxx.blob.core.windows.net/?comp=properties&restype=service": context deadline exceeded

Expected Behaviour

No response

Actual Behaviour

The domain *.core.windows.net is blocked by our company firewall, so the request to that URL is supposed to fail. As I understand it, the root cause is that azure itself does not provide the current state of static_website via the API. [Azure/azure-rest-api-specs/issues/22984]

That said, it should be possible to explicitly ignore changes and thus not trigger the refresh if disabled in lifecycle. That would allow us to create the storage and PEP as planned.

Steps to Reproduce

terraform plan

Important Factoids

No response

References

Azure/azure-rest-api-specs#22984 <- the root cause of this and the other issues
#27750
#20257
#2977

[mybayern1974]

Thank you for filing this issue. Looks like duplicate with #27310

[msteiger]

Thanks, it's very similar at least. Afaics, all referenced issues are caused by the fact that the Azure API does not deliver the data that is needed and accessing *.core.windows.net is prohibited in regulated environments.

I suggest using the lifecycle.ignore_changes flag to disable the lookup, but maybe there's a better way..?

[mybayern1974]

Thanks, it's very similar at least. Afaics, all referenced issues are caused by the fact that the Azure API does not deliver the data that is needed and accessing *.core.windows.net is prohibited in regulated environments.

I suggest using the `lifecycle.ignore_changes´ flag to disable the lookup, but maybe there's a better way..?

Per my knowledge adding ignore_changes at user side terraform config cannot resolve this issue. At present I do not have enough update and knowledge to share while please stay tuned since both Hashicorp and Microsoft is actively looking into this issue. Before any further update could be provided to mitigate this issue, here is an Terraform AzAPI provider sample solution if users could accept to use Terraform AzAPI as a workaround. The essense of that solution is it uses AzAPI to provision the Storage Account without touching Static Website, with leaving other assets still be managed by AzureRM.

[msteiger]

Thanks for the update.
I discovered that upgrading to the premium tier avoids the lookup of static_website and thus allows Terraform to successfully create the account:

  account_tier             = "Premium"
  account_replication_type = "LRS"
  account_kind             = "FileStorage"

This is just a workaround and does not solve the issue.

[bethforsyth]

I've taken the latest azurerm upgrade to 4.9.0 which contains @jackofallops fix in #27818 , with the data_plane_available set to false, and have attempted to run it against a set of resources that were previously deployed using azurerm 3.37.0 (we had not taken any intermediate updates due to this issue).

My storage account definition does not have a queue_properties block defined, but the existing tfstate file does define queue_properties - I'm assuming that presumably default values are being used.

When I run terraform plan, I get the following error

Error: 1 error occurred:
	* cannot configure 'queue_properties' when the Provider Feature 'data_plane_available' is set to 'false'
  with module.blobstore.azurerm_storage_account.endpoint_status_storage_account[0],
  on blobstore/main.tf line 99, in resource "azurerm_storage_account" "endpoint_status_storage_account":
  99: resource "azurerm_storage_account" "endpoint_status_storage_account" 

What's the intended upgrade story for setting data_plane_available = false? Ideally it would be great if there were perhaps a warning about loss of queue_properties settings (so that they could be set in azurerm_storage_account_queue_properties if needed), but for the operation to be able to continue anyway.