Azure / azure-cli

Azure Command-Line Interface
MIT License
4.01k stars 2.98k forks source link

Unable to get az policy definition create --metadata to create an array value in policy definition #29345

Open MatthewMWR opened 3 months ago

MatthewMWR commented 3 months ago

Describe the bug

Not sure if this is a bug or feature request or docs gap. Will start with bug template.

When I create a policy definition using the portal or PowerShell with category Guest Configuration, the resulting policy definition correctly includes "requiredProviders": ["Microsoft.GuestConfiguration"] in the metadata section.

I am unable to get to this same state using az policy definition create ... --metadata .....

I have tried a number of variations with different quoting and escaping schemes, including brackets in the value, not including brackets in the value, using a bash list, etc., but these all result in a policy definition where requiredProviders is some flavor of string, not an array. So far I have not found any examples online of someone getting az policy definition create --metadata to result in an array in the resulting policy definition.

Note that I am not talking about passing multiple metadata key-value pairs to --metadata. That is easily done with space delimiting. I am talking about a single KVP where the value is an array. Is it possible? If so, can the working path please be documented (or --metadata updated to take JSON like --rules and --params, rather than using its own KVP representation scheme).

Thanks.

Related command

az policy definition create

Errors

There is no immediate error. Instead the command results in an undesired/invalid policy definition. For example, (depending on input scheme attempted) "requiredProviders": "Microsoft.GuestConfiguration" rather than requiredProviders: [ "Microsoft.GuestConfiguration" ]

Issue script & Debug output

The output is extremely long due to my policy definition having a large set of params and rules logic. Not feasible to copy paste or get file to attach from isolated test environment. If possible, I will recreate the issue with a minimal policy definition and add that --debug output here.

Expected behavior

metadata section of policy definition should have a key with an array value, such as "requiredProviders": [ "Microsoft.GuestConfiguration" ]

Environment Summary

~ > az --version azure-cli 2.61.0 *

core 2.61.0 * telemetry 1.1.0

Extensions: ai-examples 0.2.5 azure-iot 0.10.13 azure-sphere 1.0.0 ml 2.26.1 resource-graph 2.1.0 ssh 2.0.3

Dependencies: msal 1.28.0 azure-mgmt-resource 23.1.1

Python location '/usr/bin/python3.9' Extensions directory '/home/matthew/.azure/cliextensions' Extensions system directory '/usr/lib/python3.9/site-packages/azure-cli-extensions'

Python (Linux) 3.9.19 (main, Mar 28 2024, 18:56:59) [GCC 11.2.0]

Legal docs and information: aka.ms/AzureCliLegal

You have 2 update(s) available. They will be updated with the next build of Cloud Shell.

Additional context

It looks like the underlying REST API takes actual JSON for the metadata input. Maybe the solution here would be to align --metadata in azcli with that (and with --rules and --params in cli, which also take actual JSON), rather than --metadata taking its own special space delimited format for KVPs.

Also, it seems weird that, input challenges aside, az policy definition create should be willing to create an invalid policy definition. I would have expected there is a schema somewhere which says requiredParameters is an array, not a string. Does that schema not exist? if it does exist, does az policy definition create not validate that the policy definition it creates is valid per the schema?

### Tasks
- [ ] Add a draft title or issue reference here
azure-client-tools-bot-prd[bot] commented 3 months ago

Hi @MatthewMWR,

2.61.0 is not the latest Azure CLI(2.62.0).

If you haven't already attempted to do so, please upgrade to the latest Azure CLI version by following https://learn.microsoft.com/en-us/cli/azure/update-azure-cli.

yonzhan commented 3 months ago

Thank you for opening this issue, we will look into it.