Connection strings stored in K8s CSI Volumes are not resolved during function discovery

Description

I have a function triggered by Service Bus connection strings. There is an issue isolated worker process: the connection string stored in container secret storage are not resolved during function discovery, causing the function to fail.

Reproduction Steps

Create an isolated Azure function project with a Service Bus trigger.
Store the service bus connection string in the file path C:\mnt\secrets-store\ with a file named ServiceBusConnection.
DO NOT include the connection string in the local.settings.json file.

Update the Program.cs to load the secret:

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureAppConfiguration((context, config) => {
        config.AddKeyPerFile("/mnt/secrets-store", false);
    })
    .Build();

await host.RunAsync();

Ensure the function uses the connection string:

[Function(nameof(ServiceBus))]
public async Task Run(
    [ServiceBusTrigger("myqueue", Connection = "ServiceBusConnection")]
    ServiceBusReceivedMessage message,
    ServiceBusMessageActions messageActions)
{
    _logger.LogInformation("Message ID: {id}", message.MessageId);
    _logger.LogInformation("Message Body: {body}", message.Body);
    _logger.LogInformation("Message Content-Type: {contentType}", message.ContentType);

    // Complete the message
    await messageActions.CompleteMessageAsync(message);
}

Start the project.

Expected behavior

The function should start with the resolved connection string.

Actual behavior

Error Message: When the app starts, the following error occurs:

The listener for function 'Functions.ServiceBus' was unable to start. Microsoft.Azure.WebJobs.Extensions.ServiceBus: Service Bus account connection string with name 'ServiceBusConnection' does not exist in the settings. Make sure that it is a defined App Setting.

Regression?

Known Workarounds

Configuration

Which version of .NET is the code running on? .NET 8

What OS and version, and what distro if applicable?

Can be reproducible with Windows 10, x64.
Observed the same issue in docker container - Linux

Other information

This issue only occurs in the isolated worker process.
The in-process model is working fine.

This isn't a runtime issue. It's a Functions issue.

But I can tell you that after having dealt with this ourselves that it is expected behavior. The isolated worker is still executed by the functions hosting runtime, which knows nothing about the app settings you add to the isolated worker project. In order to work, the value needs to be in an enviroment variable for example otherwise the functions runtime won't see it, and it's that which still processes the bindings. We hit the same issue and that's what we had to fallback on.

Once you mount the csi volume, there's options to auto create Secrets from the content of the volume, which you can then add to the container enviroment variables. It makes it a bit wonky to work with, which is why we stopped using the csi driver. It was better in our case to just use Secrets directly (which was easier via a tool like external-secrets)

dotnet / runtime