Azure-cli: az network list-service-tags requires subscription level rights

[EitZei]

Describe the bug

Command Name
az network list-service-tags

Errors:
Returns empty list if the user does not have subscription level rights. I didn't debug which rights are required but compared two logins; one that has Service Administrator to a subscription and other that does not have any role.

To Reproduce:

• az network list-service-tags --location westeurope

Expected Behavior

Listing service tags doesn't of public Azure services does not require subscription level rights.

Environment Summary

macOS-10.15.3-x86_64-i386-64bit
Python 3.8.1
Shell: bash

azure-cli 2.0.80 *

Extensions:
azure-devops 0.17.0

[yonzhan]

add to S168

[msftbot[bot]]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @aznetsuppgithub.

[MyronFanQiu]

Based on swagger spec and python sdk, subscription id is a required argument. I invited service team to take a look.

[msftbot[bot]]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @aznetsuppgithub.

[allegradomel]

Will take a look

[yonzhan]

@allegradomel please let us know any feedback.

[RichardNixon52]

Any updates on this issue?

[yonzhan]

@allegradomel any update?

[msftbot[bot]]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @vnetsuppgithub.

[allegradomel]

Quick update: we're still looking into this - I have passed it on to the dev team

[allegradomel]

My finding was that this was done by design - you must have some read access to the subscription in able to receive results from the command. Please let me know if you have any other questions, @EitZei

please-close

[matthewfrye]

I'm running into a similar issue even when I have read access at the subscription level. I can't pull back AzureCloud tags. It ends at WindowsVirtualDesktop tags.

Also, why should it be required to have read access at the subscription level to pull back publicly known IPs? You provide that info in a weekly file that requires no authentication, but you can't provide it without having read access at the subscription level?

[mgrabarz]

@allegradomel I understand this is by design, but apparently this is bad design. :)

I fully support @matthewfrye here.

[gordonpn]

@mgrabarz @matthewfrye @allegradomel

How exactly do you give read access at the subscription level to an App account? I have my account set as Owner in the scope of "This resource", but I cannot get the AzureCloud tags in the response body.

[madshaun1984]

For this API function to be of value it needs to output the same information as the publicly available file (which is not behind a subscription).

I also have owner permissions on the subscription used to call the API, I can't get the Azure Cloud tags either & I've noted that the "changeNumber: 67" in the response body is extremely outdated when compared to the publicly available file (changeNumber: 122).