How can I retrieve an Azure isolated runtime .NET 8 QueueTrigger Connection String from the Key Vault

Question

tl;dr

In an Azure Function written in .NET 8 C# in Visual Studio using the isolated runtime, is there a way to allow the Connection for a QueueTrigger to be retrieved via Microsoft.KeyVault()?

[Function("ProcessEvent")]
public void Run([QueueTrigger("my-queue", Connection = "MyConnectionString")] string myQueueItem)

When deployed to Azure, things work fine, because "MyConnectionString" is defined in the environment variables as an app settings that is:

@Microsoft.KeyVault(SecretUri=https://my-vault.vault.azure.net/MyConnectionString)

That secret is:

DefaultEndpointsProtocol=https;AccountName=my-storage-account;AccountKey=****;EndpointSuffix=core.windows.net

Again, this works fine, when deployed to Azure. However, when running locally using local.appsettings.json, the following does not work:

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "ApplicationName": "MyFunction",
    "AzureWebJobsStorage": "",
    "EventsQueueName": "my-queue",
    "MyConnectionString": "@Microsoft.KeyVault(VaultName=my-vault;SecretName=MyConnectionString)",
    ....

Nor does the long form of a Microsoft.KeyVault reference work:

     "MyConnectionString": "@Microsoft.KeyVault(SecretUri=https://my-vault.vault.azure.net/MyConnectionString)", 

However, putting the raw, secret-containing connection string into local.settings.json works:

	"MyConnectionString": "DefaultEndpointsProtocol=https;AccountName=my-storage-account;AccountKey=****;EndpointSuffix=core.windows.net",

Other locations seeking Application settings for use in my own code seem to work just fine fetching them with Microsoft.KeyVault(). This only seems to fail for the "Connection" for the isolated worker of the QueueTriggered function, which leads me to believe that my isolated process can use @Microsoft.KeyVault(), but that the actual runtime for the function, being isolated from my user code, cannot.

For context, the user under which Visual Studio 2022 is running locally has RBAC-based privileges to everything in the key vault, and the storage account. I can go to Azure Portal as the same user, and view or edit secrets, or to the store account, and view or edit queue entries or blob containers.

Microsoft says to just not check in local.settings.json to source control, but that seems silly. If a connection string's account key is rotated, every developer has to update their local settings. If this could reference the Key Vault, then when the secret is updated, all developers are still up to date without having to "spread the word".

Is there any way to allow a storage-based trigger to retrieve its connection string from the key vault?

Best Regards,

Jeff Woods

Reading, PA

Answer 1

Hi @Woods, Jeffrey Greetings! Welcome to Microsoft Q&A forum. Thank you for posting this question here.

I have tried the following settings in my local.settings.json file and made the queue trigger function access Key vault secret

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "lsayanastoragesftp_STORAGE": "@Microsoft.KeyVault(VaultName=queuetriggerconn;SecretName=queuestorageconn)"
  }
}

Make sure to set "AzureWebJobsStorage": "UseDevelopmentStorage=true" and see if you can access the end point using the secret.

Hope this helps! Please let us know if you still encounter the issue and need further assistance.

---

If the response helped, please do click Accept Answer and Yes for the answer provided. Doing so would help other community members with similar issue identify the solution. I highly appreciate your contribution to the community.

Answer 2

Hi Jeff,

Instead of directly using the Connection attribute in QueueTrigger, you could try to retrieve the connection string from Azure Key Vault at runtime. Have you tried to use a placeholder for the Connection attribute in the [QueueTrigger]. You'll need to manage connections and clients manually since automatic binding doesn't apply for runtime secret retrieval.

regards,

Digvijay