[SOLVED] Azure Redis import: "Not Found. There was no storage account called '<redacted>' in the Azure region 'Brazil South'"

Azure Redis import: "Not Found. There was no storage account called '<redacted>' in the Azure region 'Brazil South'"

Our automated Redis import started failing with this message:

Not Found. There was no storage account called '<redacted>' in the Azure region 'Brazil South'.

Our process is as follows:

Generate a SAS url:

    sas_url=$(az storage blob generate-sas \
                 -o tsv \
                 --account-name $AZ_ACCOUNT_NAME \
                 --account-key $AZ_ACCOUNT_KEY \
                 --container-name $AZ_CONTAINER_NAME \
                 --name db \
                 --permissions r \
                 --start $(date_plus_minutes -20) \
                 --expiry $(date_plus_minutes 120) \
                 --full-uri)

    az login \
       --service-principal \
       -u $AZ_SP_ID \
       -p $AZ_SP_PASS \
       --tenant $AZ_SP_TENANT

Import:

    az redis import \
       --ids $REDIS_ID \
       --files $sas_url

The Redis server and the storage account are in the same subscription and resource group.

The process works if I start the import from the web interface, and it also worked from the command-line when I used my account instead of the service principal.

I verified that when logged in as the service principal, az storage account list does not list the storage account (even though the service principal has the Storage Blob Data Contributor role in that account), but I'm not sure that it matters - the SAS token should grant access to users who wouldn't ordinarily have access, right? I have confirmed that by opening the URL and was able to download the file even when not logged in to Azure.

One thing I noticed is that in the web interface the Redis server is listed as "Location: Brazil South" and the storage account as "Location: brazilsouth". I'm not sure this is relevant, however, given that I was able to upload from the command line with a regular user.

Solution

This was solved by adding the 'Reader' role to the service principal in the storage account. (Thanks to a commenter that has deleted his comment, however.)