azure-pipelines-tasks: [BUG]: AzureFileCopy task fails when using Workload Identity Federation

The AzureFileCopyV6 task resolves this issue. It also uses Azure RBAC to access blob storage instead. This requires the identity of the service connection used to have the appropriate RBAC role e.g. Storage Blob Data Contributor. See Assign an Azure role for access to blob data.

I was able to solve it by using an AzureCLI task, maybe this will help some people:

steps:
- task: AzureCLI@2
  displayName: 'Copy ARM templates to artifact storage'
  inputs:
    azureSubscription: '<SUBSCRIPTION>'
    scriptType: pscore
    scriptLocation: inlineScript
    inlineScript: |
     az storage blob upload-batch --account-name "xartifacts" -d "artifacts" -s "$(System.DefaultWorkingDirectory)/_accountname/drop/Infrastructure/" --overwrite true
     
     $expiretime=$(date -u -d '30 minutes' +%Y-%m-%dT%H:%MZ)
     
     $connection=$(az storage account show-connection-string --resource-group "resourcegroupname" --name "xartifacts" --query connectionString)
     
     echo "##vso[task.setvariable variable=storageToken]?$(az storage container generate-sas --name artifacts --expiry $expiretime --permissions r --output tsv --connection-string $connection)"
     
     echo "##vso[task.setvariable variable=storageUri]https://xartifacts.blob.core.windows.net/artifacts"

This sets the two variables storageToken and storageUri to call the specific ARM template files I need

I was able to work around this by ditching AzureFileCopy in favor of the Azure CLI task (which properly supports workload identities) with the “az storage blob upload-batch” command:

az storage blob upload-batch --account-name <blobAccountName> -d <containerName> -s <sourceDirectory> --overwrite true

v6 was released yesterday and resolves this issue for us 😃

Yep, us too. Set up a new “Recommended” connection and our build script didn’t run and copy. Back to the old connection until there is a path forward.

Workload Identity Federation is the recommended method to create a service connection. This task should be able to support it.

Has anyone got it working or any work around for this?

We just switched back to the old authentication method for the time being.