AuthorizationPermissionMismatch when using AzureCliCredential

• Package Name: azure-identity / azure-storage-blob
• Package Version: azure-identity==1.10.0 / azure-storage-blob==12.11.0
• Operating System: Azure Pipeline (image: ubuntu-latest)
• Python Version: 3.9.12

Describe the bug When we run the following python script in Azure Devops Pipeline (using a service connection), it fails halfway through:

default_credential = AzureCliCredential()
blob_service_client = BlobServiceClient(account_url="https://MY_STORAGE_ACCOUNT.blob.core.windows.net", credential=default_credential)  
container_client = blob_service_client.get_container_client("MY_CONTAINER")  
print(container_client.exists())  # This returns True
for blob in container_client.list_blobs():  # This fails
    print(blob)

Even though this command az storage blob list -c MY_CONTAINER --account-name MY_STORAGE_ACCOUNT in the same configuration succeeds.

Here is the traceback:

True
Traceback (most recent call last):
  File "/home/vsts/work/1/s/./scripts/generate_sas_token.py", line 73, in <module>
    run()
  File "/home/vsts/work/1/s/./scripts/generate_sas_token.py", line 43, in run
    for blob in container_client.list_blobs():
  File "/opt/hostedtoolcache/Python/3.9.12/x64/lib/python3.9/site-packages/azure/core/paging.py", line 129, in __next__
    return next(self._page_iterator)
  File "/opt/hostedtoolcache/Python/3.9.12/x64/lib/python3.9/site-packages/azure/core/paging.py", line 76, in __next__
    self._response = self._get_next(self.continuation_token)
  File "/opt/hostedtoolcache/Python/3.9.12/x64/lib/python3.9/site-packages/azure/storage/blob/_list_blobs_helper.py", line 83, in _get_next_cb
    process_storage_error(error)
  File "/opt/hostedtoolcache/Python/3.9.12/x64/lib/python3.9/site-packages/azure/storage/blob/_shared/response_handlers.py", line 181, in process_storage_error
    exec("raise error from None")   # pylint: disable=exec-used # nosec
  File "<string>", line 1, in <module>
azure.core.exceptions.HttpResponseError: This request is not authorized to perform this operation using this permission.
RequestId:0ea3b6c8-101e-0006-4c24-5e7fc4000000
Time:2022-05-02T13:01:09.4026556Z
ErrorCode:AuthorizationPermissionMismatch
Content: <?xml version="1.0" encoding="utf-8"?><Error><Code>AuthorizationPermissionMismatch</Code><Message>This request is not authorized to perform this operation using this permission.
RequestId:0ea3b6c8-101e-0006-4c24-5e7fc4000000
Time:2022-05-02T13:01:09.4026556Z</Message></Error>

To Reproduce Steps to reproduce the behavior:

1. Connect to azure with azure cli
2. Execute the cli command az storage blob list -c MY_CONTAINER --account-name MY_STORAGE_ACCOUNT
3. Execute the python script given in the describe bug section

Expected behavior If both scripts authenticate the same way (which is the case here, using the azure cli), they should both have the same behavior.

Screenshots

Additional context As the bug was seen during an azure pipeline run, here is the script used to generate this pipeline:

pool:
  vmImage: ubuntu-latest
steps:
  - task: UsePythonVersion@0
    inputs:
      versionSpec: "3.9"
    displayName: Install Python
## Install the appropriate dependencies
  - task: AzureCLI@2
    inputs:
      azureSubscription: 'SERVICE_CONNECTION_NAME'
      scriptType: pscore
      scriptLocation: inlineScript
      inlineScript: |
        az storage blob list -c MY_CONTAINER --account-name MY_STORAGE_ACCOUNT --debug
        python3 my_python_script.py
      addSpnToEnvironment: true
      useGlobalConfig: true
      failOnStandardError: false
      powerShellIgnoreLASTEXITCODE: false

[jalauzon-msft]

Hi @samy-dougui Samy, thanks for reaching out. We’ll take a look and get back to you soon.

[jalauzon-msft]

Thanks for the information @DanielHabenicht! This does appear to be the likely cause of the behavior OP and others were seeing here. I wasn’t aware that the CLI had this additional functionality to query for the account key.

That being said, I don’t think the AzureCliCredential used through an SDK should be querying for the account key in this case. When using a TokenCredential (which AzureCliCredential is one of the options), the SDK is intended to use AAD Auth to connect to the Storage account. Switching to account key auth would not be the expected behavior when using this type of credential, especially since we’d have to catch the auth error from the service and then try again. Further, the AzureCliCredential is just meant to be a convenience class to help obtain the identity used in CLI, not necessarily match the auth pattern of the CLI.

The CLI is only querying for the account key here because an auth mode was not provided in the request. I expect it is not first attempting to use the AAD identity, failing, and then grabbing the account key. Further, if you were to specify --auth-mode login in the CLI request without updating the RBAC roles of the user, my hunch is that would fail in the same way the SDK does. Specifying the AzureCliCredential in the SDK request, explicitly tells the SDK to use AAD auth.

---

I also wanted to provide an additional note for everyone here and say that the RBAC role for just listing blobs should only be required to be “Storage Blob Data Reader” and not necessarily “Storage Blob Data Contributor”. This can be useful to know if you wish to restrict the permissions to read-only.