[FEATURE REQ] Allow Microsoft.Extensions.Azure to select more TokenCredentials

[mattchenderson]

Library name

Microsoft.Extensions.Azure

Please describe the feature.

Problem statement

Some users encounter issues when running in environments where there is a mix of identities, and DefaultAzureCredential probing creates a surprise. For example:

• Visual Studio run within an Azure Virtual Machine - the managed identity of the machine is picked up instead of the expected developer identity associated with Visual Studio.
• Test project runs within an ADO pipeline - the managed identity of the machine running the pipeline step is picked up instead of the expected service connection associated to the pipeline.

When setting up DefaultAzureCredential imperatively, we can use DefaultAzureCredentialOptions.ExcludeManagedIdentityCredential, but this is not available when only using the configuration-based approach. This notably occurs when configuring Azure Functions triggers and bindings through the WebJobs extensions found in this repo.

Proposed feature

One of the simplest options is probably to leverage the behavior already in place to use configuration to select between a few TokenCredential options in Microsoft.Extensions.Azure. For example, the credential property can be set to "managedidentity" to shift the behavior from DefaultAzureCredential to ManagedIdentityCredential:

azure-sdk-for-net/sdk/extensions/Microsoft.Extensions.Azure/src/Internal/ClientFactory.cs

Line 116 in 6d8cf4a

if (string.Equals(credentialType, "managedidentity", StringComparison.OrdinalIgnoreCase))

There is also a variant for WorkloadIdentityCredential. The proposal would be to introduce additional options:

credential value	TokenCrednetial implementation
"visualstudio"	VisualStudioCredential
"azurecli"	AzureCliCredential

There may be other TokenCredentials of interest as well, but these would help with the scenarios where I've been encountering more issues with Functions customers.

AzureCliCredential is specifically included based on patterns I've seen for ADO pipelines. Users will perform a CLI login through the service connection and then leverage AzureCliCredential (from code where they had imperative options), which has a simple setup process from within code. That of course can also be leveraged even through DefaultAzureCredential if ExcludeManagedIdentityCredential is set. This seems to be preferable to setting up AzurePipelinesCredential in many cases, especially when you still want to leverage flexibility of local development workflows offered by DefaultAzureCredential.

Alternatives considered

In some ways it might be simpler to introduce a new configuration option to represent ExcludeManagedIdentityCredential. However, I don't think we want to map that through for all of the Exclude* options. Leveraging the existing credential property feels like a more bounded scope.

It may also make sense to set up an AzurePipelinesCredential option, but I see its constructor takes a few additional properties beyond clientId and tenantId, which are already defined. I don't know how cleanly those can be mapped into configuration. In particular systemAccessToken gives me pause. It looks like that might have a defined environment variable that should be used already, but samples show that being captured in user code and passed into the constructor. This would need evaluation by someone before being undertaken.

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[jsquire]

Hi @mattchenderson: Enabling he full set of credentials with the current extensions packages is not a direction that we're open to. These were designed with a couple of specific production scenarios in mind and take a very basic approach to doing so. The more credentials are added, the more loose properties are supported without any structure of discoverability for which work with what credential. We'll be working to redesign our integration points with configuration and dependency injection in the future. I'll move this to the backlog so that we can take this scenario into account when we start looking to design vNext.