0
votes

My WebJobs app uses an Azure Storage Queue Trigger. It runs smoothly when the connection string to the storage account the queue app listens to is set-up in the configuration; i.e. appsettings.json.

{ "AzureWebJobsStorage": "connString" }

However, I do not want to expose any secrets in the configuration and more importantly, I'd like to avoid access keys altogether, relying on Azure AD and role-based access control (RBAC) instead.

For this, I have assigned the service principal running the application the Queue Data Contributor Role and switched in the connectivity type of the queue from Access key to Azure AD in the portal.

My intent was to use the Azure Identity SDK and new-up an instance of DefaultAzureCredential and use that to connect my app to the queue.

But as far as I can see, the Webjobs SDK expects to connect using acres key, i.e. a connection string. When using the standalone storage queue client, this is straightforward, since I can create the queue client using above-mentioned Identity SDK. However in WebJobs it seems I cannot override the means of connecting to that queue.

How can I access that queue via Azure AD and RBAC? Any help on this is greatly appreciated!

1

1 Answers

1
votes

Currently, the bindings used with the WebJobs SDK do not support using the identity SDK.

Instead, you could store the connection string in KeyVault and use the KeyVault References feature which relies on Managed Identity to fetch the secret from KeyVault at runtime.

Directly using the respective client SDK would be the way to go otherwise.