Feature Request: Option to Specify Authentication Method for Key Vault Access

[erwinkersten]

Issue Description
In environments where both Managed Identity and Azure CLI credentials are available (e.g., systems with Azure Arc connectivity utilizing a Managed Identity), it appears that accessing Azure Key Vault via notation-azure-kv defaults to using the Managed Identity for authentication, ignoring Azure CLI credentials. This behavior limits flexibility in scenarios where it might be necessary or desirable to use Azure CLI credentials for Key Vault access instead of the Managed Identity.

Proposed Solution
Introduce functionality to explicitly specify the desired authentication method when accessing Azure Key Vault. This enhancement would allow users to override the default behavior (Managed Identity precedence) and select between Managed Identity or Azure CLI credentials. It would be great if we can specify this via plugin arguments:

--plugin-config authentication_method=azurecli   
--plugin-config authentication_method=managedidentity

If no authentication_method argument is specified the defautl behaviour where managedidentity has precedence is preffered particularly for pipeline automation.

[rennerg]

I second this. We are currently blocked by this due to notation-azure-kv attempting to use the managed identity of our build machines which are part of a different tenant than the key vault we are attempting to use for signing. We use the Azure CLI and even setting the subscription context right before calling notation-azure-kv does not help.

[yizha1]

Thanks @erwinkersten and @rennerg. We will need some time to solve this issue, would you mind trying EnvironmentCredential to unblock you?

This current behavior is per the API, see
https://learn.microsoft.com/en-us/dotnet/api/azure.identity.managedidentitycredential?view=azure-dotnet, the order is as follows, so managed identity in your case is always selected.

EnvironmentCredential
WorkloadIdentityCredential
ManagedIdentityCredential
SharedTokenCacheCredential
VisualStudioCredential
VisualStudioCodeCredential
AzureCliCredential
AzurePowerShellCredential
AzureDeveloperCliCredential
InteractiveBrowserCredential

/cc @shizhMSFT @JeyJeyGao

[akashsinghal]

#154 will also benefit from this work as a workaround

[rennerg]

I was able to get around this by setting these environment variables right before calling notation sign:

• AZURE_TENANT_ID
• AZURE_CLIENT_ID
• AZURE_CLIENT_SECRET

[JeyJeyGao]

A new credential_type selection feature was introduced in #157, resolving the issue.