Security improvement by moving away from "DefaultAzureCredential"

[doormalena]

The following is written on https://learn.microsoft.com/en-gb/dotnet/api/azure.identity.defaultazurecredential?view=azure-dotnet stating that "DefaultAzureCredential" is not to be used in production scenarios.

Simplifies authentication while developing apps that deploy to Azure by combining credentials used in Azure hosting environments with credentials used in local development. In production, it's better to use something else. See [Usage guidance for DefaultAzureCredential](https://aka.ms/azsdk/net/identity/credential-chains#usage-guidance-for-defaultazurecredential).

Consider allowing the user of AzureSignTool to specify which credential is to be used via a new additional parameter related to --azure-key-vault-managed-identity. For example, my needs would be the "WorkloadIdentityCredential". For others, this could be InteractiveBrowserCredential or anything else.

[wimmme]

And maybe add some logging which method is used.
We are struggling big time figuring out which one is used.
The framework has the possibility to enable logging.
I am not a developer, I would do it myself and create a PR but this not my cup of tea ...
https://learn.microsoft.com/en-us/dotnet/azure/sdk/authentication/credential-chains?tabs=dac#usage-guidance-for-defaultazurecredential

https://learn.microsoft.com/en-us/dotnet/azure/sdk/logging

[doxxx]

Yeah, this is a real pain for me, because somehow AzureSignTool is using some implicitly created appid corresponding to the VM it's running on, instead of the system-managed or user-managed identities I've assigned to the VM. This is making it very hard to grant access to the key vault.

[Geet2009]

I'm also facing the same issue, appid created is not available on Azure to provide the access to keyvault. Please let me know when this issue will be resolved.

[tomlaf]

Same issue.
The kvm use the device identity and there is no way, that I find, to force it to use anyother.