Azure / azure-functions-dotnet-worker

Azure Functions out-of-process .NET language worker
MIT License
403 stars 166 forks source link

App Insights doesn't work when local auth is disabled #2447

Open xqrzd opened 1 month ago

xqrzd commented 1 month ago

Description

Disabling local auth for App Insights breaks ingestion. It's an isolated .NET 8 function, using the method described here. I also attempted to apply this for Entra ID authentication, though it's not exact as the function SDK seems a bit different.

The function has the 'Monitoring Metrics Publisher' role. Using OpenTelemetry with App Service works great, but OpenTelemetry doesn't work with functions. I was not able to find any exact documentation for how to enable Entra ID authentication for App Insights for functions specifically.

Side rant, this is the 3rd time now I've had to weaken security to get Azure Functions working. No VNET support https://github.com/azure/azure-functions/issues/646 means I have to make every resource the function touches public facing, and https://github.com/microsoft/azure-pipelines-tasks/issues/18105 means the function can't use a managed identity to authenticate with the required storage account.

Steps to reproduce

This was the registration code I tried that failed,

services.AddApplicationInsightsTelemetryWorkerService(
    opt => opt.ConnectionString = hostContext.Configuration.GetValue<string>("APPLICATIONINSIGHTS_CONNECTION_STRING");
services.ConfigureFunctionsApplicationInsights();
services.Configure<TelemetryConfiguration>(config =>
{
    var credential = new DefaultAzureCredential();
    config.SetAzureTokenCredential(credential);
});
jamesadevine commented 1 month ago

@RohitRanjanMS Is there any update here? Also cannot enable the use of entra IDs with app insights from an azure function.

jhueppauff commented 4 days ago

@xqrzd Regarding your side rant - when using public runner, I used to have a pipeline job which adds the IP of the runner to the ACLs of the affected resources (storage, function app, sql, keyvault etc). It is not great, but unless using private runner the only option. Just as an idea if you do not want to use private runners which are in the network of the private endpoints of the storage, function, etc.

I am currently mostly on Gitlab for some reasons - there we use just the plain Azure CLI which works like a charm for authentication.

I know this example uses app registrations - but our storage accounts are configured with disable shared key access:

az login --service-principal -u $ARM_CLIENT_ID -p $ARM_CLIENT_SECRET --tenant $ARM_TENANT_ID
az account set -s $ARM_SUBSCRIPTION_ID
func azure functionapp publish $name --dotnet-isolated

So it should properly work with MSI as well.