Upgrade storage client & support Entra identities for storage in more scenarios

[aelij]

Issue describing the changes in this PR

Resolves #3376

Pull request checklist

• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• I have added all required tests (Unit tests, E2E tests)

PR overview:

• Upgrade to the latest Storage client
• Use AzureCliCredential and AzurePowerShellCredential to fetch an access token instead of the code that calls the CLIs
  • Note I intentionally did not use DefaultAzureCredential to preserve the current behavior, as it might require the user to specify a tenant ID under certain conditions
• Support AzureWebJobsStorage__accountName in more scenarios:
  • Linux Consumption - fetches the storage account key using ARG+ARM and uses it to create the required SAS URI
  • Linux Elastic - combined code with Dedicated, as both support run from package
• Remove old unused app.config (.NET Framework relic)

[xanecs]

Hi, I've tried your fork and with a few minor exceptions, it worked perfectly and solved my deployment problem. Thank you!

There are just two small changes I've made to allow working with a Storage Account that has Shared Keys turned off.

[xanecs]

Remove the StorageSharedKeyCredential and use this.Credential instead.
This allows disabling Shared Keys on the storage account altogether.

[xanecs]

Again, to allow disabling Shared Keys on the storage account, return blob.Uri in case managed identity is used.

[CrawX]

I would be awesome if this could get merged & released. Making my storage account accessible via managed identity only led me to this PR, due to this not being merged yet I was forced to switch to WEBSITE_RUN_FROM_PACKAGE which seems to ignore requirements.txt which in turn leads to all kinds of other failures (see Azure/azure-functions-python-worker#1262 for a fun example) and a lot of wasted time. I'd love to see this merged.

[aelij]

@Azure/azure-functions-worker-owners @mattchenderson PTAL

[Copilot]

Pull Request Overview

This PR upgrades the storage client and supports Entra identities in more scenarios by updating how access tokens are fetched and modifying ARM calls. Key changes include:

• Replacing legacy token retrieval with a chained AzureCliCredential/AzurePowerShellCredential approach.
• Refactoring ARM client usage by renaming ArmClient to CliArmClient and updating all corresponding calls.
• Modifying storage package upload logic to use the new Azure Storage SDK with SAS URI generation and adding a new constant for AzureWebJobsStorageAccountName.

Reviewed Changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/Azure.Functions.Cli/Arm/ArmClientExtensions.cs	Introduces storage account lookup using ARM and new record types.
src/Azure.Functions.Cli/Actions/AzureActions/PublishFunctionAppAction.cs	Updates deployment logic and container upload to use the new storage SDK.
src/Azure.Functions.Cli/Common/Constants.cs	Adds a constant for AzureWebJobsStorageAccountName.
src/Azure.Functions.Cli/Actions/AzureActions/BaseAzureAction.cs	Switches to chained credentials and refactors initialization order.
src/Azure.Functions.Cli/Common/SimpleProgressBar.cs	Changes progress reporting to use IProgress.
Multiple test files and AzureHelper.cs	Update to reference CliArmClient instead of the legacy ArmClient.

Comments suppressed due to low confidence (2)

src/Azure.Functions.Cli/Helpers/AzureHelper.cs:1031

• The call to 'ArmClient.FindStorageAccount' appears to use a static reference even though the extension method is defined on an instance of ResourceManager.ArmClient. Consider providing an appropriate ArmClient instance (or using CliArmClient if intended) to ensure proper runtime behavior.

var storageAccount = await ArmClient.FindStorageAccount(accountName);

src/Azure.Functions.Cli/Actions/AzureActions/BaseAzureAction.cs:93

• Since GetAccessToken constructs its TokenRequestContext using ManagementURL (by appending '/.default'), ensure that ManagementURL is always initialized before calling GetAccessToken to avoid potential runtime errors.

if (string.IsNullOrEmpty(ManagementURL)) { ManagementURL = await GetManagementURL(); } if (string.IsNullOrEmpty(AccessToken)) { AccessToken = await GetAccessToken(); }