Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

windows_function_app app settings combination fails in sovereign cloud #25892

Open
1 task done
bloomingdave opened this issue May 7, 2024 · 4 comments
Open
1 task done

Comments

@bloomingdave
Copy link

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 "+1" or "me too" comments, 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.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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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+d__11.MoveNext
type
Azure.RequestFailedException
assembly
Azure.Identity, Version=1.10.2.0, Culture=neutral, PublicKeyToken=92742159e12e44c8
method
Azure.Identity.ManagedIdentitySource+d__11.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
Copy link

I ran into a similar issue with sovereign cloud compatibility

#24824

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants