`az storage container generate-sas` returns 'self.account_key should not be None'

[jochenvw]

Trying to generate a SAS key for my storage account obviously. I have a storage account with a container inside called drop and a policy on it, called client.

Here's is the full command with parameter values:

az storage container generate-sas \
-n drop \
--auth-mode login \
--policy-name client \
--account-name [name]

As the error states, I did not specify account key, and here's why:

az storage container policy show \
-c drop \
--name client \
--auth-mode login \
--account-name [name]

This works fine. I thought --auth-mode login results in not needing an --account-key as you're using the AAD identity to perform the operation. Am I correct and so, is this a bug?

Second point of feedback: in policy show, the container name is specified with -c, whereas in generate-sas, it's through -n. Is this deliberate, or maybe an inconsistency ?

This is autogenerated. Please review and update as needed.

Describe the bug

Command Name az storage container generate-sas

Errors:

self.account_key should not be None.
Traceback (most recent call last):
pip-install-rtk110ve\knack\knack\cli.py, ln 206, in invoke
cli\core\commands\__init__.py, ln 603, in execute
cli\core\commands\__init__.py, ln 661, in _run_jobs_serially
cli\core\commands\__init__.py, ln 652, in _run_job
cli\command_modules\storage\__init__.py, ln 248, in new_handler
cli\command_modules\storage\__init__.py, ln 191, in handler
cli\core\commands\__init__.py, ln 631, in _run_job
cli\core\commands\__init__.py, ln 305, in __call__
azure\cli\core\__init__.py, ln 485, in default_command_handler
command_modules\storage\operations\blob.py, ln 460, in generate_container_shared_access_signature
storage\v2018_11_09\blob\baseblobservice.py, ln 421, in generate_container_shared_access_signature
storage\v2018_11_09\common\_error.py, ln 130, in _validate_not_none
ValueError: self.account_key should not be None.

To Reproduce:

Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

• az storage container generate-sas -n {} --auth-mode {} --policy-name {} --account-name {}

Expected Behavior

Environment Summary

Windows-10-10.0.18362-SP0
Python 3.6.6
Shell: cmd.exe

azure-cli 2.0.70

Extensions:
interactive 0.4.3
storage-preview 0.2.8

Additional Context

[Juliehzl]

1. --auth-mode login will find account credentials according to your login information. In this way, in "login" auth mode, you don't need to specify --account-key. But I think the reason you get this error message maybe that you are using a storage account which not in the login subscription. You can check using az account show to find the default subscription and verify if your storage account is in this subscription. I f not, you can change the default subscription using az account set -s yoursubid.

2. In policy show, the operation target is policy not container, so we use --name for policy name and the container name is specified with -c. But in generate-sas, the target is container, so we define container name using -n.

[Juliehzl]

@jochenvw what about your problem now?

[simonbrady]

I can consistently reproduce this in 2.0.75 by setting AZURE_STORAGE_SAS_TOKEN in the shell environment. My theory is that if the environment variable is set, the generate-sas command tries to use the token for authorisation, finds the token doesn't grant it sufficient permissions, then falls back to requiring an account key instead. After unsetting AZURE_STORAGE_SAS_TOKEN I can no longer reproduce the error.

Seems to be the same behaviour as #9346.

[mhennecke]

@Juliehzl: I'm able to reproduce this issue with AzureCloud as well as AzureChinaCloud. Service principals are used for az login in both environments.

I made sure that the default subscription is the one where the storage accounts resides in, as you suggested. There is no AZURE_STORAGE_SAS_TOKEN environment variable set.

az storage container generate-sas -n <container_name> --account-name <account_name> --expiry $(date -u -d "1 hour" '+%Y-%m-%dT%H:%MZ') --auth-mode login

Errors:

self.account_key should not be None.
Traceback (most recent call last):
python3.6/site-packages/knack/cli.py, ln 206, in invoke
    cmd_result = self.invocation.execute(args)
cli/core/commands/__init__.py, ln 578, in execute
    raise ex
cli/core/commands/__init__.py, ln 636, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
cli/core/commands/__init__.py, ln 627, in _run_job
    cmd_copy.exception_handler(ex)
...
storage/v2018_11_09/blob/baseblobservice.py, ln 421, in generate_container_shared_access_signature
    _validate_not_none('self.account_key', self.account_key)
storage/v2018_11_09/common/_error.py, ln 130, in _validate_not_none
    raise ValueError(_ERROR_VALUE_NONE.format(param_name))
ValueError: self.account_key should not be None.

Environment Summary

Linux-4.4.0-18362-Microsoft-x86_64-with-debian-buster-sid
Python 3.6.5
Shell: bash

azure-cli 2.0.69 *
azure-cli-iot-ext 0.7.1

Extensions:
azure-cli-iot-ext 0.7.1

[yonzhan]

any update for this issue?

[mhennecke]

Still able to reproduce this issue with azure-cli 2.0.80

[qianwens]

You need to remove parameter "--auth-mode" from the command as below: az storage container generate-sas --account-name --expiry 2020-01-01 --name --permissions dlrw Generate-sas needs the storage account key, if you specify --auth-mode login in the command, cli will try to use the login access token to generate sas which is not supported If both --auth-mode and --accountKey are not specified, cli will get the accountKey using the access token and generate sas token with the accountKey.

[qianwens]

Close this issue since there is no response. Please help create a new issue if you still have questions.