Feature Request: Support Managed Service Identity for Storage connections

[PhoenixHe-NV]

Please provide a succinct description of the issue.

Repro steps

Currently Azure Storage supports Managed Service Identity. But azure webjob sdk only spports connection string for storage account. It would be great that webjob sdk support MSI.

Known workarounds

I've found some workarounds by inject storage account on registering. First I need to generate the CloudStorageAccount by MSI in advance. Then, there are two services I need to inject:

var blobClient = storageAccount.CreateCloudBlobClient();
var container = blobClient.GetContainerReference("webjob-lock");

var builder = new HostBuilder()
   .ConfigureWebJobs(b =>
   {
     b.Services.AddSingleton(new DistributedLockManagerContainerProvider
     {
       InternalContainer = container
     });
     b.Services.AddSingleton<StorageAccountProvider>(new ManagedIdentityStorageAccountProvider(storageAccount));

     b.AddAzureStorageCoreServices();
     b.AddAzureStorage();
     b.AddTimers();
   })

public class ManagedIdentityStorageAccountProvider : StorageAccountProvider
{
  private readonly CloudStorageAccount storageAccount;

  public ManagedIdentityStorageAccountProvider(CloudStorageAccount storageAccount) : base(null)
  {
    this.storageAccount = storageAccount;
  }

  public override StorageAccount Get(string name)
  {
    return StorageAccount.New(this.storageAccount);
  }
}

I'm still looking for official MSI support.

[PhoenixHe-NV]

Any update on this one?

[ross-p-smith]

The above code fails for me as the StorageCredentails does not have an AccountName when created with a Token Credential. This would work if we could approve Pull Request #2000

[mmusin]

A year had passed...

[mdddev]

I want to try out the proposed workaround of @NullMDR but I am to inexperienced to actually apply it properly. Unfortunately the information in the code snippet provided, I don't know where to actually implement it. Is this program.cs or function.cs? Sorry for the lack of knowledge..

[mdddev]

Nevermind the above, it appears I have not read thoroughly enough.
The way I see it, you're explicitly defining the kind of storage account (i.e. the way it is created) in the DI. I am still new to all this, so apologies.

[mdddev]

FYI, this is working for Service Bus and Event Hub. Jeff Hollan, principal pm on the azure functions team informed on the reason why this is on twitter

https://twitter.com/jeffhollan/status/1260600212617179137

[cn894]

Hi, my team is still looking for official MSI support in the SDK. Has there been any update on this issue?

[GoradeAarti]

We are looking for official MSI support to get rid of storage connection string for WebJobs. any update on this issue?

[Erikvdv]

After a long search I found out it is now possible by just adding some settings in your appsettings.json:

"AzureWebJobsStorage": { "blobServiceUri": "https://{storageaccount}.blob.core.windows.net/", "queueServiceUri": "https://{storageaccount}.queue.core.windows.net/" },

[thegrahamking]

After a long search I found out it is now possible by just adding some settings in you appsettings.json:

"AzureWebJobsStorage": { "blobServiceUri": "https://{storageaccount}.blob.core.windows.net/", "queueServiceUri": "https://{storageaccount}.queue.core.windows.net/" },

Did you find this in the documentation?

[Erikvdv]

Found it in the azure functions docs:
https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference?tabs=blob#common-properties-for-identity-based-connections

[franklixuefei]

it works for me using the following settings in appsettings.config with the latest release of the storage extension (5.0.0)

"AzureWebJobsStorage": {
    "accountName": "moxycpsa"
    // the following 2 lines need to be commented out in local dev mode. 
    // Otherwise, the Microsoft.Azure.WebJobs.Extensions.Storage extension will
    // try only to connect to MSI service ignoring local windows/azcli creds.
    // ONLY ENABLE THE FOLLOWING IN PROD ENV
    //"credential": "managedidentity",
    //"clientId": ""
  }

However, if webjobs.AddDurableTask(); is specified, then the above won't work, and the work around for that is using MSI to retrieve the account key and assemble the connection string:

private static string BuildAzureStorageConnectionString(IConfiguration config)
{
    var accountName = config.GetValue<string>("AzureWebJobsStorage:accountName");
    var subscription = config.GetValue<string>("AzureWebJobsStorage:subscription");
    var resourceGroup = config.GetValue<string>("AzureWebJobsStorage:resourceGroup");
    var clientId = config.GetValue<string?>("AzureWebJobsStorage:clientId", default);

    var creds = new DefaultAzureCredential(new DefaultAzureCredentialOptions
    {
        ManagedIdentityClientId = clientId,
    });
    var management = new ArmClient(creds);

    Console.WriteLine($"[{DateTime.UtcNow.ToString("u")}]\tGetting storage keys...");
    var account = management.GetStorageAccount(StorageAccount.CreateResourceIdentifier(subscription, resourceGroup, accountName));
    var keys = account.GetKeys();
    var key = keys.Value.Keys.First(k => k.Permissions == KeyPermission.Full).Value;
    Console.WriteLine($"[{DateTime.UtcNow.ToString("u")}]\tStorage key retrieved.");
    return $"DefaultEndpointsProtocol=https;AccountName={accountName};AccountKey={key};EndpointSuffix=core.windows.net";
}