hashicorp / terraform-provider-azurerm

Terraform provider for Azure Resource Manager
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs
Mozilla Public License 2.0
4.6k stars 4.65k forks source link

windows_function_app app settings combination fails in sovereign cloud #25892

Open bloomingdave opened 6 months ago

bloomingdave commented 6 months ago

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

resource "azurerm_windows_function_app" "function" {
  name                = "my-fa"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  service_plan_id     = azurerm_service_plan.service_plan[0].id
  identity {
    type         = "UserAssigned"
    identity_ids = [azurerm_user_assigned_identity.managed_identity.id]
  }
  key_vault_reference_identity_id = azurerm_user_assigned_identity.managed_identity.id
  storage_uses_managed_identity = true
  storage_account_name = local.function_app_backend_storage_account_name
  app_settings = {
    MiClientId = azurerm_user_assigned_identity.managed_identity.client_id
    AzureWebJobStorage_blobServiceUri = "https://sa.blob.core.usgovcloudapi.net/"
    AzureWebJobStorage_queueServiceUri = "https://sa.queue.core.usgovcloudapi.net/"
    AzureWebJobStorage_tableServiceUri = "https://sa.table.core.usgovcloudapi.net/"
    WEBSITE_RUN_FROM_PACKAGE_BLOB_MI_RESOURCE_ID = azurerm_user_assigned_identity.managed_identity.id
    WEBSITE_RUN_FROM_PACKAGE = data.azurerm_storage_blob.WEBSITE_RUN_FROM_PACKAGE_zip_blob.url   
    },
 }

Debug Output/Panic Output

This configuration, using the storage_account_name parameter, applied in the Government cloud, will deploy the app setting AzureWebJobStorage_accountname which will not apply a cloud specific URI to the storage account name in this setting. 

testing removal of the storage_account_name parameter gives you the following:

"storage_account_name": one of `storage_account_name,storage_key_vault_secret_id` must be specified

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

bloomingdave commented 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.

bloomingdave commented 6 months ago

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.

bloomingdave commented 6 months ago

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+d11.MoveNext type Azure.RequestFailedException assembly Azure.Identity, Version=1.10.2.0, Culture=neutral, PublicKeyToken=92742159e12e44c8 method Azure.Identity.ManagedIdentitySource+d11.MoveNext outerType Microsoft.Azure.WebJobs.Host.Listeners.FunctionListenerException outerMessage The listener for function 'CopySaToSa' was unable to start. innermostType Azure.RequestFailedException innermostMessage Service request failed. Status: 400 (Bad Request)

Content: {"statusCode":400,"message":"Unable to load the proper Managed Identity.","correlationId":"87b3fded-b3ee-4ba9-bb3d-1d922a1c7231"}

nbjohnson commented 6 months ago

I ran into a similar issue with sovereign cloud compatibility

https://github.com/hashicorp/terraform-provider-azurerm/issues/24824