Application Insights Entra Based Auth for Local Development

[LeonardHd]

Local development of Azure Functions with Application Insights is not possible when local authentication is disabled using the azure-functions-core-tools aka func CLI. This is because the ManagedIdentityCredential (as implemented in TokenCredentialOptions) is not supported in local development. This feature request is to enable local development of Azure Functions with Application Insights when local authentication is disabled.

Entra-based authentication for the azure-functions-host was introduced with #9835. This feature allows the host to authenticate using Entra-based authentication using the ManagedIdentityCredential using APPLICATIONINSIGHTS_AUTHENTICATION_STRING. This is required for scenarios where Application Insight has local authentication disabled (see Microsoft Entra authentication for Application Insights) and Azure Function Host telemetry should be pushed to Application Insights.

In scenarios in which Azure landing zones have local authentication disabled for Application Insights, developers are unable to push telemetry from Azure Functions to Application Insights locally in their development flow with the func CLI. This is because:

1. ManagedIdentityCredential is not supported in local development,
2. The APPLICATIONINSIGHTS_CONNECTION_STRING is not sufficient to authenticate with Application Insights.

This is problematic because developers are unable to:

1. test their telemetry locally before deploying to Azure,
2. debug telemetry issues locally,
3. replicate their production telemetry setup locally.

Describe the solution you'd like

A proposed solution is to enable local development of Azure Functions by allowing to configure other credential types for Application Insights. A common credential is the DefaultAzureCredential which supports multiple authentication methods including ManagedIdentityCredential. Alternatively, the configuration could allow specific credential types suited for local development (derived from TokenCredential).:

• DefaultAzureCredential

or

• AzureCliCredential
• AzureDeveloperCliCredential
• VisualStudioCredential
• VisualStudioCodeCredential

To support this feature, the TokenCredentialOptions could be extended to support additional credential types. Given that ManagedIdentityCredential is already supported, implementation should be backwards compatible, yet allow for additional credential types to be configured.

A proposed configuration via APPLICATIONINSIGHTS_AUTHENTICATION_STRING could be:

1. Match ClientId=<>;Authorization=AAD first and use ManagedIdentityCredential as implemented in TokenCredentialOptions.

2. If no such configuration is found try to match (non-exhaustive list):

   • Authorization=ManagedIdentity;ClientId=<>; for user-assigned ManagedIdentityCredential,
   • Authorization=ManagedIdentity; for system-assigned ManagedIdentityCredential,
   • Authorization=AzureCli; for AzureCliCredential (i.e, az login).

This minimal configuration allows for local development of Azure Functions with Application Insights when local authentication is disabled but still use ManagedIdentityCredentials for the existing configuration.

Additional configuration options and credential types could (later) easily be added. New types by matching new Authorization values in the APPLICATIONINSIGHTS_AUTHENTICATION_STRING. New configuration options for the matching credential type in the Authorization value could be added by appending these as additional key-value pairs in the APPLICATIONINSIGHTS_AUTHENTICATION_STRING. For example: Authorization=AzureCli;TenantId=<>; for AzureCliCredential with specific TenantId.

As a result, configuration is backward compatible and allows for additional credential types to be configured.

Describe alternatives you've considered

• Using Application Insights with local authentication enabled. Not possible for scenarios where local authentication is disabled by default, also not possible to replicate production telemetry setup.

• Using additional configuration options in local.settings.json (i.e., not the existing APPLICATIONINSIGHTS_AUTHENTICATION_STRING . Introducing additional configuration adds complexity and future maintenance. Extending the APPLICATIONINSIGHTS_AUTHENTICATION_STRING is a more flexible and maintainable solution.

Related information

Configuration available on Azure environment (with a system or user assigned managed identity)

Envisioned configuration for local development flows

Tagging @MahrRah, @ransonjb

[RohitRanjanMS]

Hi @LeonardHd thank you for creating this issue and providing additional details and context. The APPLICATIONINSIGHTS_AUTHENTICATION_STRING is owned by the Azure Monitor team, meaning they define its structure and format. I recommend adhering to their guidelines.
Although I have integrated support for this in the host, there are other components such as the agents (Java, Python and Node), profiler, and snapshot debugger that also supports this env variable and sends telemetry to ApplicationInsights but these components are owned and managed by the Azure Monitor team. While we could modify the host to support local development, it would cause incompatibility issues with these other components. We previously discussed local development support and decided against it to avoid a fragmented experience for our customers.

Adding @BigMorty, we were talking about this yesterday.

[LeonardHd]

Hi Rohit, ok I understand, and I agree that APPLICATIONINSIGHTS_AUTHENTICATION_STRING is not the place to enable a local development flag. At the moment, we do not have a possibility to test the observability fully in a local environment which increases feedback time and complexity to integrate observability into solutions.

Any chance we could re-consider local development support through an additional flag as enterprise environments might lock down all their Log Analytics workspaces and require Entra Id authentication by default policy in landing zones.