Can I use DefaultAzureCredential with Zero User Code Lightup?

[carlin-q-scott]

The Microsoft.ApplicationInsights.Kubernetes.HostingStartup library can be loaded by kestrel through a single environment variable, and the connection string can be supplied by another environment variable. What if I want to use the DefaultAzureCredential provided by Azure.Identity? Is it automatically used? Or do I have to register it somehow using code or another environment variable?

I'm using this in a pod that has a workload (managed) identity assigned to its service account with access to my App Insights instance.

[xiaomi7732]

Hi @carlin-q-scott, this is an interesting question. The question actually roots to whether can we turn on DefaultAzureCredential for application insights without code, right?

How do you use DefaultAzureCrednetial normally? Is there any code involved?

[carlin-q-scott]

Yes, I have to set the token credential on the telemetry configuration using this code:

appBuilder.Services
    .Configure<TelemetryConfiguration>(config =>
    {
        config.SetAzureTokenCredential(new DefaultAzureCredential());
    })

At least that's what the documentation says. You'd think that it would be used by default considering the name though. I'm unsure if I can call that method to set credentials for the auto instrumentation.

[xiaomi7732]

Hey @carlin-q-scott, sorry for the late reply.

Let's check what the issue is. To setup token credential for application insights (for managed identity or any other token auth), we need to have access to 2 libraries at the same time: Microsoft.ApplicationInsights & Azure.Identity.

In hosting startup scenario (zero code light up), we will have to have both on the dependency tree to make it work, and then there has to be code to set the token credential like the code you shared above.

Then, there could be an environment variable to decide whether to turn it on or off.

Could be some code here.

Technically, I believe it is doable.

That said, I'd rather keep zero code startup as simple as possible - less dependency, less code. Looking for a sweet spot.

Question for you: what attracts you to the Zero Code Lightup? TBH, it is more like a magic, not easy to debug, and more unpredictable than the normal experience. Do you have a scenario that Zero Code Lightup is a must? Please help me understand it, thanks!

[carlin-q-scott]

Zero Code is nice to have for me. I like the idea of the Kubernetes App Insights operator that will inject the agent where applicable so that developers can focus on their code and not instrumentation for hosted environments. Currently I'm not enforcing auth for my App Insights workspace because the endpoint and key are not exposed publicly. But eventually they will be. So at that time I will have to modify the code for of all my team's applications to use credentials. It would be nice if that could be done through configuration instead.

I get what you're saying about the complexity of implementing this with zero code. It would require reflection to make Azure.Identity an optional package. And there's risk in this library making assumptions about authentication because the application code could have its own authentication scheme that might differ from whatever we assume here.

[xiaomi7732]

Hey @carlin-q-scott, thank you so much for letting me know your situation. Here's an idea: write your own startup library, and have all your projects reference to it. Today, it starts up Application Insights without credentials. And in the future, when you are ready to turn it on, release a new version of the library and ask the various projects to bump up the versions. Will that address your concern?

You are right that it isn't too good an idea for us to assume the token provider. But you shall be able to do it in your library because you will know the concretes.