When I started updating the GitHub AT-AT to support Azure Functions Flex Consumption, I assumed it would be straightforward. The azurerm_function_app_flex_consumption resource is supported in the AzureRM provider, and since our security policies at Microsoft require Managed Identity, I made using it the default in every experiment or deployment I do.

Terraform provisions the resource fine, the app shows up in the portal, and I see the Flex Consumption SKU happily listed. But then you actually try to deploy your code — kind of the entire point — and everything falls apart.

The Deployment Pipeline and the Wall I Hit

My GitHub Actions workflow deploys using the Azure CLI under a user-assigned managed identity. During the deployment step, I get:

ERROR: Failed to fetch host key to check for function app status

Alt

It turns out I’m not alone. Others have filed issues, like FlexConsumption Deployment AzureDevops Error · Issue #10620 · Azure/azure-functions-host, struggling to transition to Flex Consumption with real workloads.

https://github.com/Azure/azure-functions-host/issues/10620

This person was using Bicep but its probably not too far off what I am provisioning with Terraform. I’m using:

  • dotnet-isolated runtime on .NET 8
  • Deployment via Terraform and Bicep (in other repos)
  • GitHub Actions with Managed Identity and Azure CLI for deployment.

What Actually Happens Behind the Scenes I can see that the Azure CLI is successfully publishing my released-package.zip to the Function App’s blob container, alongside kudu-state.json. So, the CLI is uploading files, but the app never comes online properly, and the deployment hangs or fails.

Alt

I suspected the managed identity used by GitHub Actions might need access to the storage account that the Function App uses for its host keys and content storage.

Alt

This suspicion was reinforced when I hit this error:

Azure.Storage.Blobs: Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. RequestId:9a86550f-501e-00bc-6073-e4dc90000000 Time:2025–06–23T19:18:58.7378892Z Status: 403 (Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.) ErrorCode: AuthenticationFailed Additional Information: AuthenticationErrorDetail: The MAC signature found in the HTTP request ‘YxZCD1fYtoK4xQvO8b0CpjmMoUf//Z+Os+0kxf3+klo=’ is not the same as any computed signature. Server used following string to sign: ‘GET x-ms-client-request-id:f1289d47–17e8–4057-a17b-d0ffe0481f6a x-ms-date:Mon, 23 Jun 2025 19:18:58 GMT x-ms-return-client-request-id:true x-ms-version:2023–11–03 /stfuncmm1qfysx/azure-webjobs-secrets restype:container’. Content: <?xml version=”1.0" encoding=”utf-8"?><Error><Code>AuthenticationFailed</Code><Message>Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. RequestId:9a86550f-501e-00bc-6073-e4dc90000000 Time:2025–06–23T19:18:58.7378892Z</Message><AuthenticationErrorDetail>The MAC signature found in the HTTP request ‘YxZCD1fYtoK4xQvO8b0CpjmMoUf//Z+Os+0kxf3+klo=’ is not the same as any computed signature. Server used following string to sign: ‘GET x-ms-client-request-id:f1289d47–17e8–4057-a17b-d0ffe0481f6a x-ms-date:Mon, 23 Jun 2025 19:18:58 GMT x-ms-return-client-request-id:true x-ms-version:2023–11–03 /stfuncmm1qfysx/azure-webjobs-secrets restype:container’.</AuthenticationErrorDetail></Error> Headers: Server: Microsoft-HTTPAPI/2.0 x-ms-request-id: 9a86550f-501e-00bc-6073-e4dc90000000 x-ms-error-code: AuthenticationFailed Date: Mon, 23 Jun 2025 19:18:58 GMT Content-Length: 779 Content-Type: application/xml .

Alt

This usually means the Function App cannot read or write to its AzureWebJobsStorage.

Configuring App Settings for Managed Identity

Flex Consumption still requires AzureWebJobsStorage, so I added: I apparently still need AzureWebJobStorage so I added the following app Settings:

app_settings = {

  "AzureWebJobsStorage__blobServiceUri"            = azurerm_storage_account.function.primary_blob_endpoint
  "AzureWebJobsStorage__queueServiceUri"           = azurerm_storage_account.function.primary_queue_endpoint
  "AzureWebJobsStorage__tableServiceUri"           = azurerm_storage_account.function.primary_table_endpoint
  "AzureWebJobsStorage__credential"                = "managedidentity"
  "AzureWebJobsStorage__clientId"                  = azurerm_user_assigned_identity.function.client_id
  "AzureWebJobsStorage__managedIdentityResourceId" = azurerm_user_assigned_identity.function.id

}

It looks like its all setup when I go look at it in the Azure Portal.

Alt

I have given the User Assigned Managed Identity access to the following Role Definitions:

  • Storage Account Contributor
  • Storage Blob Data Contributor

Alt

Perhaps I should try a different Secret Storage Provider Clearly, the Azure Functions runtime is super pissed off about my Azure Storage Account and it can’t seem to access azure-webjobs-secrets on the Storage Account. Perhaps I just need to try and replace the Storage Account storage strategy with a different, even better one — like KeyVault. Why would Azure Functions even store “secrets” in Blob Storage by default anyway? That’s kind of nuts right? So I adjust the app settings of my Function App to use KeyVault instead.

app_settings = {

  // MOAR!!!

  "AzureWebJobsSecretStorageType"                  = "keyvault"
  "AzureWebJobsSecretStorageKeyVaultClientId"      = azurerm_user_assigned_identity.function.client_id
  "AzureWebJobsSecretStorageKeyVaultUri"           = azurerm_key_vault.main.vault_uri
}

Despite these changes, I ran into:

Azure.Security.KeyVault.Secrets: Caller is not authorized to perform action on resource. If role assignments, deny assignments or role definitions were changed recently, please observe propagation time. Caller: appid=188d398e-9078–4c20–9f00-ef38c2e10f5f;oid=0f9b0290-cfa7–470d-bb71–6b3289949161;iss=https://sts.windows.net/b3e9c6a3-6c4e-4d1b-ac51-c4ad419be440/ Action: ‘Microsoft.KeyVault/vaults/secrets/setSecret/action’ Resource: ‘/subscriptions/9db8d5ac-a7c8–4882–9720-d0c3424699d7/resourcegroups/rg-qonq-share-prod-eastus2/providers/microsoft.keyvault/vaults/kv-qonq-share-prod1/secrets/host — functionkey — default’ Assignment: (not found) DenyAssignmentId: null DecisionReason: null Vault: kv-qonq-share-prod1;location=eastus2 Status: 403 (Forbidden) ErrorCode: Forbidden Content: {“error”:{“code”:”Forbidden”,”message”:”Caller is not authorized to perform action on resource.\r\nIf role assignments, deny assignments or role definitions were changed recently, please observe propagation time.\r\nCaller: appid=188d398e-9078–4c20–9f00-ef38c2e10f5f;oid=0f9b0290-cfa7–470d-bb71–6b3289949161;iss=https://sts.windows.net/b3e9c6a3-6c4e-4d1b-ac51-c4ad419be440/\r\nAction: ‘Microsoft.KeyVault/vaults/secrets/setSecret/action’\r\nResource: ‘/subscriptions/9db8d5ac-a7c8–4882–9720-d0c3424699d7/resourcegroups/rg-qonq-share-prod-eastus2/providers/microsoft.keyvault/vaults/kv-qonq-share-prod1/secrets/host — functionkey — default’\r\nAssignment: (not found)\r\nDenyAssignmentId: null\r\nDecisionReason: null \r\nVault: kv-qonq-share-prod1;location=eastus2\r\n”,”innererror”:{“code”:”ForbiddenByRbac”}}} Headers: Cache-Control: no-cache Pragma: no-cache x-ms-keyvault-region: eastus2 x-ms-client-request-id: fe0b78dc-3e89–4120–8dc2–652887619aff x-ms-request-id: f0f3357a-0389–4893-bb78-ada75623efaa x-ms-keyvault-service-version: 1.9.2497.1 x-ms-keyvault-network-info: conn_type=Subnet;addr=172.24.12.51;act_addr_fam=InterNetworkV6; X-Content-Type-Options: REDACTED Strict-Transport-Security: REDACTED Date: Tue, 24 Jun 2025 18:28:40 GMT Content-Type: application/json; charset=utf-8 Expires: -1 Content-Length: 809 .
It turns out that giving the function’s managed identity Key Vault Secrets User access is insufficient. The Function App needs to set secrets for its host keys, requiring the Microsoft.KeyVault/vaults/secrets/setSecret/actionpermission.

After adjusting the Key Vault RBAC to include Key Vault Administrator temporarily, the error went away, but the deployment still failed with the same “Failed to fetch host key” errors.

After each of these changes I still receive the same deployment error when my GitHub Action attempts to deploy the code.

Alt

The Core Problem

Here’s the real issue:

  • Terraform provisions Flex Consumption with Managed Identity fine, but the runtime and deployment pipeline fail.
  • The Function App expects to read/write its host keys and content via storage, but managed identity-based connections are not fully supported across all required operations.
  • The system throws authentication or host key retrieval errors, and deployment workflows time out.

It should be straightforward, but it is not.

Shouldn’t This Be Easy?

You would think deploying code to a newly provisioned Function App using Managed Identity would “just work,” especially with a supported Terraform resource and Azure CLI deployment. But Flex Consumption is still early, and the Function App’s dependence on storage for runtime operation collides with using managed identity without falling back to connection strings.

If your organization enforces Managed Identity for all workloads, this can leave you in a limbo where:

  • The app provisions but cannot run.
  • Deployment workflows break.
  • No clear guidance exists for fully managed identity-backed Flex Consumption deployments.

Where to Go From Here

I opened an issue on GitHub for this

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

If you are hitting similar issues, please add your scenarios and vote on the issue so we can push for a clear, supported path forward.

Until then, Flex Consumption + Managed Identity + CI/CD deployment is not a smooth path, and may require falling back to connection strings temporarily or skipping Flex Consumption in environments with strict managed identity requirements.

Alt