Azure-cli: Complaint about API version with az role assignment command

[buchs]

This is autogenerated. Please review and update as needed.

Describe the bug

CLI command fails to execute with complaint about the API version not being supported.

Command Name
az role assignment create

Errors:

The api-version '2018-01-01-preview' is invalid. The supported versions are '2019-08-01,2019-07-01,2019-06-01,2019-05-10,2019-05-01,2019-03-01,2018-11-01,2018-09-01,2018-08-01,2018-07-01,2018-06-01,2018-05-01,2018-02-01,2018-01-01,2017-12-01,2017-08-01,2017-06-01,2017-05-10,2017-05-01,2017-03-01,2016-09-01,2016-07-01,2016-06-01,2016-02-01,2015-11-01,2015-01-01,2014-04-01-preview,2014-04-01,2014-01-01,2013-03-01,2014-02-26,2014-04'.

To Reproduce:

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

• install CLI on Ubuntu 18.04 per instructions: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view=azure-cli-latest
• az role assignment create --assignee cf32a0cc-373c-47c9-9156-0db11f6a6dfc --role Contributor --scope /subscriptions/$subscription/resourceGroups/$imageResoureGroup

Came from following this guide: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/image-builder

Expected Behavior

no errors

Environment Summary

Linux-4.15.0-1050-oem-x86_64-with-debian-buster-sid
Python 3.6.5
Shell: bash

azure-cli 2.0.73 *

Additional Context

[buchs]

Just updated CLI, same behavior.

$ az --version
azure-cli 2.0.74

command-modules-nspkg 2.0.3
core 2.0.74
nspkg 3.0.4
telemetry 1.0.3

Python location '/opt/az/bin/python3'
Extensions directory '/home/kbuchs/.azure/cliextensions'

Python (Linux) 3.6.5 (default, Sep 20 2019, 05:42:39)
[GCC 7.4.0]

Legal docs and information: aka.ms/AzureCliLegal

Your CLI is up-to-date.

[buchs]

Debugging logs
debugging-on.txt

[buchs]

I found, in the end, that the error was nothing about api-versions. Please consider creating an appropriate error message. I had misspelled one of the shell variables I was using to define the scope. So the last segment of the scope, following the slash was unpopulated and the scope was actually subscriptions/$subscription/resourceGroups/.

[jiasli]

@buchs, thanks for the investigation. Judging from the debug log, it is indeed caused by the incorrect scope which lacks the resource group name:

/subscriptions/{subscription_id}/resourceGroups/
                                                ^ resource group name is missing

So the HTTP request becomes:

msrest.http_logger : Request URL: 'https://management.azure.com/subscriptions/{subscription_id}/resourceGroups/providers/Microsoft.Authorization/roleDefinitions?$filter=roleName%20eq%20%27Contributor%27&api-version=2018-01-01-preview'

msrest.http_logger : Response status: 400
msrest.http_logger : Response content:
msrest.http_logger : {"error":{"code":"InvalidApiVersionParameter","message":"The api-version '2018-01-01-preview' is invalid. The supported versions are '2019-08-01,2019-07-01,2019-06-01,2019-05-10,2019-05-01,2019-03-01,2018-11-01,2018-09-01,2018-08-01,2018-07-01,2018-06-01,2018-05-01,2018-02-01,2018-01-01,2017-12-01,2017-08-01,2017-06-01,2017-05-10,2017-05-01,2017-03-01,2016-09-01,2016-07-01,2016-06-01,2016-02-01,2015-11-01,2015-01-01,2014-04-01-preview,2014-04-01,2014-01-01,2013-03-01,2014-02-26,2014-04'."}}

The URL is corrupted and ARM falls back to the default Resource Groups REST API, instead of Role Assignments REST API.

The same error message can be produced with an incorrect api-version:

> az rest -m GET -u "https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups?api-version=2020-01-02"
Bad Request({"error":{"code":"InvalidApiVersionParameter","message":"The api-version '2020-01-02' is invalid. The supported versions are '2020-01-01,2019-11-01,2019-10-01,2019-09-01,2019-08-01,2019-07-01,2019-06-01,2019-05-10,2019-05-01,2019-03-01,2018-11-01,2018-09-01,2018-08-01,2018-07-01,2018-06-01,2018-05-01,2018-02-01,2018-01-01,2017-12-01,2017-08-01,2017-06-01,2017-05-10,2017-05-01,2017-03-01,2016-09-01,2016-07-01,2016-06-01,2016-02-01,2015-11-01,2015-01-01,2014-04-01-preview,2014-04-01,2014-01-01,2013-03-01,2014-02-26,2014-04'."}})

Let me see how we can polish the error.

[yonzhan]

add to S170

[jiasli]

I did some further investigation and found 2 ways to refine the error:

1. Catch the exception and refine it

Currently the exception is handled at

https://github.com/Azure/azure-cli/blob/e6e437a80639616c9871d1d9248bbb1a65be268e/src/azure-cli-core/azure/cli/core/util.py#L71-L80

The exception caught by Azure CLI is a CloudError. If we check here whether the error message contains InvalidApiVersionParameter and point out it is caused by invalid --scope, it will pollute other commands. Especially in Azure Stack, InvalidApiVersionParameter is a common error.

So we need to register a custom exception handler:

https://github.com/Azure/azure-cli/blob/0ce0448c9cbe73faa26c56ffcc9bc10bbf3b30f2/src/azure-cli-core/azure/cli/core/commands/__init__.py#L1213

But still, we can't tell whether this is caused by wrong scope or real invalid api-version, thus causing confusions.

2. Validate the scope before sending the request

We pre-validate the scope in https://github.com/Azure/azure-cli/blob/37d15261c516bc095236ddb1155dbcc470daf79b/src/azure-cli/azure/cli/command_modules/role/_validators.py#L98

However, it is very difficult to fully mimic the behavior of ARM. I tried to use is_valid_resource_id from azure-mgmt-core but this function still leaves some invalid edge-case scopes uncaught (https://github.com/Azure/azure-sdk-for-python/issues/11658).

[ashu3496]

Faced similar issue. The error message is misleading and it has nothing to do with version. After removing the last asterix(*) from AssignableScopes, it worked for me.

ashutosh.singh:~$ az role definition create --role-definition '{ \
>     "Name": "RoleViaCli", \
>     "Description": "My role via Cli", \
>     "Actions": [ \
>         "Microsoft.Compute/*/read", \
>             "Microsoft.Compute/virtualMachines/start/action", \
>             "Microsoft.Compute/virtualMachines/restart/action" \
>     ], \
>     "AssignableScopes": ["/subscriptions/XXXXXXXXXXXXXXXXXXXXX/*"] \
> }'

The api-version '2018-01-01-preview' is invalid. The supported versions are '2020-06-01,2020-05-01,2020-01-01,2019-11-01,2019-10-01,2019-09-01,2019-08-01,2019-07-01,2019-06-01,2019-05-10,2019-05-01,2019-03-01,2018-11-01,2018-09-01,2018-08-01,2018-07-01,2018-06-01,2018-05-01,2018-02-01,2018-01-01,2017-12-01,2017-08-01,2017-06-01,2017-05-10,2017-05-01,2017-03-01,2016-09-01,2016-07-01,2016-06-01,2016-02-01,2015-11-01,2015-01-01,2014-04-01-preview,2014-04-01,2014-01-01,2013-03-01,2014-02-26,2014-04'.

After removing asterix(*), it just worked.

ashutosh.singh:~$ az role definition create --role-definition '{ \
>     "Name": "RoleViaCli", \
>     "Description": "My role via Cli", \
>     "Actions": [ \
>         "Microsoft.Compute/*/read", \
>             "Microsoft.Compute/virtualMachines/start/action", \
>             "Microsoft.Compute/virtualMachines/restart/action" \
>     ], \
>     "AssignableScopes": ["/subscriptions/XXXXXXXXXXXXXXXXXX/"] \
> }'
{
  "assignableScopes": []
}

[jiasli]

@ashu3496, looks like a separate issue. I will take a look when time permits.

[jjohndrow]

This seems broken to me at the api level. I'm just using postman against the azure api directly via the instructions here https://docs.microsoft.com/en-us/azure/role-based-access-control/role-assignments-list-rest. Its blocking me right now.

Scoped at subscription level it succeeds
https://management.azure.com/subscriptions/:subscriptionId/providers/Microsoft.Authorization/roleAssignments/?api-version=2015-07-01

Narrow that scope to resource group it Fails.
https://management.azure.com/subscriptions/:subscriptionId/resourceGroup/:resourceGroupName/providers/Microsoft.Authorization/roleAssignments/?api-version=2015-07-01

{
"error": {
"code": "InvalidApiVersionParameter",
"message": "The api-version '2015-07-01' is invalid. The supported versions are '2020-07-01,2020-06-01,2020-05-01,2020-01-01,2019-11-01,2019-10-01,2019-09-01,2019-08-01,2019-07-01,2019-06-01,2019-05-10,2019-05-01,2019-03-01,2018-11-01,2018-09-01,2018-08-01,2018-07-01,2018-06-01,2018-05-01,2018-02-01,2018-01-01,2017-12-01,2017-08-01,2017-06-01,2017-05-10,2017-05-01,2017-03-01,2016-09-01,2016-07-01,2016-06-01,2016-02-01,2015-11-01,2015-01-01,2014-04-01-preview,2014-04-01,2014-01-01,2013-03-01,2014-02-26,2014-04'."
}
}