Open bloomingdave opened 6 months ago
Ultimately I need the storage_account_name to apply a cloud appropriate URI, or the check that enforces the use of 'storage_account_name' or 'storage_key_vault_secret_id' be removed.
My apologies, when I submitted this issue I thought 3.83.0 was the latest version. I am testing 3.102.0 now and I am nearly certain that the 'storage_account_name' or 'storage_key_vault_secret_id' check remains but with the latest version and 'storage_account_name' and 'storage_uses_managed_identity' my initial test show this working.
I have to test with a real function app now, but the initial issue with not being able to reach the backend storage seems to be fixed. I will test and come back and provide my updates and whether this should be closed.
I will add that the documentation has not caught up if 'AzureWebJobStorage_acccountname' will indeed now work with sovereign clouds.
BLUF: I still need the check that enforces 'storage_account_name' or 'storage_key_vault_secret_id' be removed. We wish to use the MI so we don't want the key vault secret with a connection string and 'storage_account_name" forces the AzureWebJobsStorage_accountname app settign on us, which fails in government cloud.
The new provider version allows our FA to reach the zip files in our 'application-zips' container but fails to access the 'azure-webjob-hosts' container. This is seen by the function in the FA's overview page showing up as green and displaying the function name, but it throws the attached error. Why this is doesn't make sense, they both either use the MI or don't, I presume.
here is the highlight from the attached error.txt,
timestamp [UTC]
2024-05-08T19:36:00.8136327Z
problemId
Azure.RequestFailedException at Azure.Identity.ManagedIdentitySource+
Content: {"statusCode":400,"message":"Unable to load the proper Managed Identity.","correlationId":"87b3fded-b3ee-4ba9-bb3d-1d922a1c7231"}
I ran into a similar issue with sovereign cloud compatibility
https://github.com/hashicorp/terraform-provider-azurerm/issues/24824
Is there an existing issue for this?
Community Note
Terraform Version
1.6.0
AzureRM Provider Version
3.83.0
Affected Resource(s)/Data Source(s)
azurerm_windows_function_app
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
Initially and per the included configuration file above, you would expect the backend storage account (SA) to be configured to be accessed by the function app (FA) using its user assigned managed identity (MI). However, this configuration only works for the public cloud.
Actual Behaviour
The FA's parameter "storage_account_name" configures an app setting name "AzureWebJobsStorage_accountname". The value shown in the Azure portal simply displays the SA name with no URI added. But as the FA functions will not start or reach the blob file containing the function's compiled code zip file, and with the following documentation, it is understood the URI added to this app setting is the Azure public cloud's URI.
Also, per the documentation, link below in references, you see that sovereign clouds cannot use the result of the storage_account_name, which is AzureWebJobsStorage_accountname, but instead should use AzureWebJobsStorage__*ServiceUri. I have included those in my config, but I can never deploy an FA with the azurerm_windows_function_app resource as I must either include the storage_account_name or storage_key_vault_secret_id, as per this the error in the Debug Output section above.
Steps to Reproduce
terraform apply with the config provided gives you an unusable AzureWebJobsStorage_accountname app setting.
Removing the terraform azurerm_windows_functions_app parameter that causes this app setting will give the error shown in the debug section.
Important Factoids
I am having this issue in the Government cloud
References
https://learn.microsoft.com/en-us/azure/azure-functions/functions-app-settings#azurewebjobsstorage__accountname