az functionapp deployment fails when deploying to an app with identity based connection for storage

[paulbatum]

Describe the bug Deploying to a function app that uses an identity based connection for AzureWebJobsStorage (e.g. AzureWebJobsStorage__accountName) fails validation when running az functionapp deployment source config-zip.

To Reproduce Follow the steps outlined here.

Expected behavior Deployment should complete.

Actual behavior Deployment fails with the error Could not find a 'AzureWebJobsStorage' application setting

Environment summary azure-cli 2.11.0 core 2.11.0 telemetry 1.0.5

Extensions: appservice-kube 0.1.7

Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe' Extensions directory 'C:\Users\pbatum.azure\cliextensions'

Python (Windows) 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 23 2018, 23:31:17) [MSC v.1916 32 bit (Intel)]

Additional context

Looks like this validation logic is the problem: https://github.com/Azure/azure-cli/blob/d1676f65bc643396ea1f562ac29cf2c66cd55d05/src/azure-cli/azure/cli/command_modules/appservice/custom.py#L539-L545

[msftbot[bot]]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @ahmedelnably, @fabiocav.

Issue Details

---

Describe the bug Deploying to a function app that uses an identity based connection for AzureWebJobsStorage (e.g. AzureWebJobsStorage__accountName) fails validation when running az functionapp deployment source config-zip.

To Reproduce Follow the steps outlined here.

Expected behavior Deployment should complete.

Actual behavior Deployment fails with the error Could not find a 'AzureWebJobsStorage' application setting

Environment summary azure-cli 2.11.0 core 2.11.0 telemetry 1.0.5

Extensions: appservice-kube 0.1.7

Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe' Extensions directory 'C:\Users\pbatum.azure\cliextensions'

Python (Windows) 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 23 2018, 23:31:17) [MSC v.1916 32 bit (Intel)]

Additional context

Looks like this validation logic is the problem: https://github.com/Azure/azure-cli/blob/d1676f65bc643396ea1f562ac29cf2c66cd55d05/src/azure-cli/azure/cli/command_modules/appservice/custom.py#L539-L545

Author:	paulbatum
Assignees:	-
Labels:	Functions, Service Attention
Milestone:	-

[yonzhan]

route to service team

[gzuber]

Thanks @paulbatum, it looks like this is going to require some additional changes because we assume it's going to be a connection string here.

[pragnagopa]

When not using Azure Files but using Managed Identity for AzureWebJobsStorage

az functionapp deployment should default to remote build. As the app is not using Azure Files, if using Run from package =1, content will upload to data\sitePackages - Windows Consumption, Dedicated, Linux Dedicated.

When using Azure Files but using Managed Identity for AzureWebJobsStorage

• Remote build does not work without key vault references or full connection string. This is currently blocked on Azure Files supporting mounting vis Managed Identity.

[jbpaux]

Any idea when it would be fixed ? :)

[sayandaw]

Any Estimate on the fix ? Seems the main thread is locked and being looked into?
https://github.com/Azure/azure-functions-core-tools/issues/2671

[ArunasFalcon]

In case anyone stumbles over this issue, I found a workaround. Basically setting the config setting core tools is looking for, then running core tools, then restore the original settings. I made a PS wrapper script for the core tools call to make this work until core tools get fixed. So if anyone needs a quick&dirty solution, here it is: https://github.com/ArunasFalcon/MIAzureFunctionDeployWrapper

[panchagnula]

This issue belong to the azure-functions-core-tools

[fardarter]

Has there been any attention on this?

[Quixotical]

getting the same issue, this seems very strange that functionality would be documented by MS but be unworkable when used. (If I can't do a deployment because of a Microsoft documented permissions configuration, specifically user assigned identites, I am calling that unworkable since deployments are critical)

I have enabled a user assigned managed identity and verified that on my running application, the permissions are valid. I then made a small change to my code and attempted to deploy it when I received the following error

'dev-pedls-api-user-function' app is missing AzureWebJobsStorage app setting. That setting is required for publishing consumption linux apps.

[fardarter]

So this is doable if you use WEBSITE_RUN_FROM_PACKAGE from a storage upload. Below is a working deployment.

resource "azurerm_linux_function_app" "function_app" {
  name                          = "linux-function-app"
  resource_group_name           = var.resource_group_data.functions_app.name
  location                      = var.resource_group_data.functions_app.location
  service_plan_id               = azurerm_service_plan.function_app_service_plan.id
  storage_account_name          = var.storage_accounts.functions.name
  storage_uses_managed_identity = true
  https_only                    = true
  builtin_logging_enabled       = false

  identity {
    type = "SystemAssigned"
  }

  app_settings = {
    # See: https://docs.microsoft.com/en-us/azure/azure-functions/run-functions-from-deployment-package
    WEBSITE_LOCAL_CACHE_OPTION = "Never" # incompatible with run as package
    WEBSITE_RUN_FROM_PACKAGE   = <url to storage>
  }
  site_config {
    app_scale_limit                        = 5
    application_insights_connection_string = azurerm_application_insights.application_insights.connection_string
    application_insights_key               = azurerm_application_insights.application_insights.instrumentation_key
    scm_use_main_ip_restriction            = true
    ip_restriction = [
      {
        headers                   = []
        action                    = "Allow"
        name                      = "AllowEventGrid"
        service_tag               = "AzureEventGrid"
        ip_address                = null
        priority                  = 400
        virtual_network_subnet_id = null
      },
      {
        headers                   = []
        action                    = "Deny"
        ip_address                = "0.0.0.0/0"
        name                      = "DenyAll"
        priority                  = 500
        service_tag               = null
        virtual_network_subnet_id = null
      }
    ]
    application_stack {
      python_version = var.python_version
    }
  }
  lifecycle {
    # See: https://github.com/hashicorp/terraform-provider-azurerm/issues/16569
    ignore_changes = [
      tags["hidden-link: /app-insights-instrumentation-key"],
      tags["hidden-link: /app-insights-resource-id"]
    ]
  }
}

[Quixotical]

@fardarter I saw that option but this azure doc made me hesitant to use the URL option. It seems like there's a lot of drawbacks to it. Have you noticed anything w/ cold starts, or having to handle manually syncing triggers?

[fardarter]

@fardarter I saw that option but this azure doc made me hesitant to use the URL option. It seems like there's a lot of drawbacks to it. Have you noticed anything w/ cold starts, or having to handle manually syncing triggers?

I'm using the md5 hash to trigger a restart from the terraform side. Cold starts don't matter for us in the context here so not really been looking at it.