Unable to debug function app locally when using managed identity-based blob bindings and triggers

Please provide a succinct description of the issue.

The documentation for using identity-based connections with the default AzureWebJobsStorage and custom connection is very thorough and complete. It is easy to setup a sample that works for both use cases.

However, I find myself unable to debug the function app locally because it appears that the functions host runtime only uses a subset of all credential providers. Specifically, it does not honor either VisualStudioCredential, the VisualStudioCodeCredential, the AzurePowerShellCredentials nor the AzureCLICredential providers.

As can be seen in the following screenshot, the functions host runtime only uses the DefaultAzureCredential, the EnvironmentCredential and the ManagedIdentityCredential providers.

Repro steps

Provide the steps required to reproduce the problem

1. On Azure, create a function app, using a consumption plan. Choose .NET 6.0 as the language and version. This creates a function app and a corresponding storage account and application insights resource.

2. Navigate to the function app that has been created and enable its system-assigned managed identity.

3. Navigate to the storage account associated with the function app and add role assignments for the function app identity. Add the Storage Blob Data Contributor, Storage Queue Data Contributor and Storage Table Data Contributor roles.

4. Create a container named container.

5. Create a secondary storage account, and add role assignments for the function app identity. Add the Storage Blob Data Contributor role.

6. Create a container named container.

7. Create a new .NET function app project in Visual Studio or Visual Studio Code, and use the following code:

[FunctionName("Functions")]
public async Task<IActionResult> Run(
	[HttpTrigger(AuthorizationLevel.Function, "post", Route = null)] HttpRequest req,
	[Blob("container", FileAccess.Read, Connection = "AzureWebJobsStorage")] BlobContainerClient container,
	[Blob("container", FileAccess.Read, Connection = "MyCustomConnection")] BlobContainerClient msi,
	ILogger log,
	CancellationToken cancellationToken)
{
	await WriteBlobAsync(container, "hello.txt", log);
	await WriteBlobAsync(msi, "hello.txt", log);
}

private async Task WriteBlobAsync(BlobContainerClient container, string blobName, ILogger log)
{
	try
	{
		var blob = container.GetBlockBlobClient(blobName);
		using (var stream = await blob.OpenWriteAsync(true))
		using (var writer = new StreamWriter(stream))
			writer.WriteLine("Hello, world!");
	}
	catch (Exception e)
	{
		log.LogError(e.Message);
	}
}

This code exposes a simple HTTP endpoint and writes a sample text file in both default and custom storage accounts. Using managed identity is a matter of specifying appropriate application settings.

1. On Azure, navigate to the function app and enable managed identity for the default AzureWebJobsStorage connection. Simple, rename the AzureWebJobsStorage application setting to AzureWebJobsStorage__accountName and change its value to simply refer to the account name – and not the connection string.

2. Likewise, enable managed identity for the custom MyCustomConnection connection. Create an application setting named MyCustomConnection__blobServiceUri and set its value to a URI that looks like https://account.blob.core.windows.net where account is a placeholder for the real account name.

Expected behavior

While the function app works successfully when hosted on Azure, it cannot be debugged locally from either Visual Studio or Visual Studio Code. I expect to be able to hit <kbd>F5</kbd> and debug locally.

Actual behavior

Instead, the functions host runtime tries to use some credential providers but fails to find a suitable token. As a result, the function start fails with permission issues.

Known workarounds

N/A

Related information

Provide any related information

Here is a extract from the .csproj file:

  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.Functions.Extensions" Version="1.1.0" />
    <PackageReference Include="Microsoft.Azure.Services.AppAuthentication" Version="1.6.0" />
    <PackageReference Include="Microsoft.Azure.WebJobs.Extensions.Storage" Version="5.0.1" />
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
  </ItemGroup>

[mattchenderson]

DefaultAzureCredential should use the local developer identity. The providers mentioned as not being supported (VisualStudioCredential, VisualStudioCodeCredential, AzurePowerShellCredentials, AzureCLICredential) are included within DefaultAzureCredential. However, please note that VisualStudioCodeCredential has a known issue for certain versions.

If there is a suitable role assignment for you as you are signed into those, then that should be fine. The sequence of credential providers will each be given a chance to provide a token, and from there, the system should use that. It could be that an earlier provider within DefaultAzureCredential. I don’t know what to make of the network error shown in the original screenshot. That doesn’t seem connected to any specific repro steps. Overall, this seems to be working in our testing, and we do not have a reproduction of this issue. At present, I can’t identify an action for us on this one.

It should be noted that the AzureWebJobsStorage connection specifically remains in preview for identity support. I don’t think that should factor into the core workflow at this point, but I did want to note that qualifier. I would try again with updated host and extension versions. It may also be good to upgrade / re-login to your Azure CLI, etc. I apologize that this issue wasn’t responded to sooner. My hope is that you were able to get this working in the interim. If it’s still presenting an issue, please let us know.

[msftbot[bot]]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.