Better Azure Identity support

[jmezach]

I recently read this blog post by @asimmon about providing a better experience when using the developers Azure Identity during local development with .NET Aspire. I was thinking that it would be great to have that experience provided by this community toolkit. @asimmon Would you be open to that?

[asimmon]

It would be great to have better Azure Identity support in Aspire. I'm unavailable to contribute, but I could provide more information than in my blog post.

We've been using this for months in my company (with a twist, but the concept remains the same), as many teams consume containerized .NET services from other teams. We use Azure Identity to access resources like key vaults, app configs, etc.

Problems solved

• Containerized apps that rely on Azure Identity can now access Azure resources using the developer's identity from the host machine.
• Any app using DefaultAzureCredential (from any language/SDK) may have a faster startup time (9 seconds saved in the best scenario).

Existing workaround

Before Aspire came out, we published an Azure CLI credential proxy. It's a sidecar-ish container that provides the Azure CLI credentials to containerized apps from a mounted directory on the host machine. It works, but it is not ideal as it requires manual steps.

The implementation in this project is more complete than my blog post, as we had external contributions to cover more use cases (like az login --identity in this PR).

Public API

We could start thinking about the public API exposed to developers so that they can leverage this feature in Aspire. In my blog post, I've created this builder.AddAzureCliCredentialProxy() that would return a custom proxy resource. Referencing this resource with WithReference would provide the environment variables to the caller.

Right now, they can override the resource name and port. By default, the resource name is az-cli-proxy, and the port is random. Do you think this is good enough?

Behavior

In my blog post, I described the Azure CLI credential proxy as a custom resource orchestrated by a custom lifecycle hook. The resource is shown in the dashboard to see other apps' calls when they request an access token. Is this the behavior we want?

As the proxy would stop when stopping the dashboard, any persistent container referencing the proxy would no longer be able to authenticate against Azure. Is this a limitation we're ready to have? I would assume most people would use persistent containers for databases, but I'm not sure.

The credential used in the lifecycle hook should be new ChainedTokenCredential(new AzureCliCredential(), new DefaultAzureCredential()) instead of new AzureCliCredential(). It would be as fast and support authentication sources other than Azure CLI only.