Why Does AzCopy Login Fail with --identity in Azure DevOps Workload Identity Federation?

The error

ManagedIdentityCredential: failed to authenticate a system assigned identity. The endpoint responded with {"error":"invalid_request","error_description":"Identity not found"}

indicates that AzCopy is being asked to use an identity (with the --identity flag) that isn’t available on the hosted pipeline agent. In other words, the command

  azcopy login --identity

expects a system‐assigned (or user‐assigned) managed identity available to the runtime environment (for example, on an Azure VM or App Service with a managed identity assigned). However, in an Azure DevOps pipeline on a Microsoft-hosted agent, this managed identity does not exist.

Why It Fails

• Managed Identity Unavailable: The pipeline agent (ubuntu-latest) does not expose a managed identity since it is not running in an environment that has one.
• Mismatch in Authentication Method: While your service connection uses workload identity federation (a form of service principal authentication), the command you’re using (with --identity) tries to retrieve a managed identity from the host environment.

How to Fix

Option 1: Use Service Principal Credentials Directly

Since you already have the service principal details available from the pipeline environment variables (servicePrincipalId, idToken, tenantId), you can log in to AzCopy with a service principal rather than using a managed identity. For example, if AzCopy supports passing a service principal and token (or password/certificate), adjust your login command accordingly. Verify the AzCopy authentication docs for the proper parameters.

A possible alternative might be:

BASHCopied
azcopy login --service-principal --application-id "$servicePrincipalId" --tenant-id "$tenantId" --service-principal-key "$servicePrincipalKey"

Note: In the above example, you would need to have the service principal key available as an environment variable. With workload identity federation using OIDC, check whether AzCopy has updated support to consume an OIDC token directly (if not, you might need to adjust your authentication approach).

Option 2: Perform an Azure CLI Login and Reuse Its Credentials

If the AzureCLI@2 task is already logging you in (because of azureSubscription being specified), you could potentially avoid a separate AzCopy login. Instead, you can rely on the authenticated context provided by the Azure CLI. You could try to run your AzCopy command after ensuring that the Azure CLI is logged in. For example:

BASHCopied
az login --allow-no-subscription
# Now run AzCopy commands that might leverage this context
azcopy copy "source" "destination" --recursive

Note: Make sure that the necessary permissions (Storage Blob Data Contributor) are in place for the service principal used in your service connection.

Summary

The issue is that your build agent does not have a managed identity, so using “azcopy login --identity” fails. You need to authenticate using the service principal details provided by the Azure DevOps service connection (or use a different login method that fits the agent's environment). Adjust your authentication method accordingly to resolve the error.