Using Azure managed identity for authenticating to Azure Storage and Azure Tables

[mbonica703]

Is your feature request related to a problem? Please describe.

I'm running BaGetter on an Azure VM with a managed identity. I'd like to use the VM's managed identity to authenticate to Azure Blob Storage and Azure Table Storage, instead of a connection string with a hardcoded key or SAS token.

Describe the solution you'd like

I'd like BaGetter to automatically try to use DefaultAzureCredential if a ConnectionString isn't set. (I'd also need to be able to set the storage account name and table/container names separately from the connection string.)

Describe alternatives you've considered

ConnectionString works, I just need to handle securing and rotating the SAS token, which is work I wouldn't have to do if I could use the VM's managed identity.

[Regenhardt]

This seems easily implemented.

In AzureApplicationExtensions, instead of new StorageSharedKeyCredential(options.AccountName, options.AccessKey) we pass new ManagedIdentityCredential() and that's it.

Need a fitting API to do it though. Maybe set the ConnectionString to "ManagedIdentity" and check for that? Seems hacky.
ConnectionString empty and set AccessKey to "ManagedIdentity"? Still hacky.
Leave both ConnectionString and AccessKey empty? This might be the most intuitive.

I'm open to ideas, preferably ones that don't change current behaviour.

[Regenhardt]

Instead of just ManagedIdentityCredential, there is also DefaultAzureCredential, which tries multiple credential providers in order to find one that works. Environment first, managed third, cli and VS later on. This has a performance-tradeoff though and could be unpredictable due to trying multiple providers automatically so maybe keep the configuration more specific.

[mbonica703]

Thanks for considering this!

I think DefaultAzureCredential would be appropriate. The reason I say so is that the AWS SDK also does something very similar, see https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/creds-assign.html; it automatically iterates through credentials, set profiles, env vars, mounted tokens in a container, and finally instance metadata.

I'm fairly used to expecting a tool that uses a public cloud SDK to go "hands-off" and let the SDK do its own thing when figuring out authenticating to that cloud, so that doesn't bother me.

I agree that it makes sense in this scenario for "AccessKey" and "ConnectionString" being empty leading to falling back on DefaultAzureCredential (for Azure), and initializing S3 client without credentials (for AWS).