Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
1 task
MatthewMWR opened this issue Jul 9, 2024 · 2 comments
Assignees
Labels
ARM az resource/group/lock/tag/deployment/policy/managementapp/account management-group Auto-Assign Auto assign by bot Auto-Resolve Auto resolve by bot Azure CLI Team The command of the issue is owned by Azure CLI team question The issue doesn't require a change to the product in order to be resolved. Most issues start as that
Milestone

Comments

@MatthewMWR
Copy link

MatthewMWR commented Jul 9, 2024

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

@MatthewMWR MatthewMWR added the bug This issue requires a change to an existing behavior in the product in order to be resolved. label Jul 9, 2024
Copy link

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.

@azure-client-tools-bot-prd azure-client-tools-bot-prd bot added the Auto-Resolve Auto resolve by bot label Jul 9, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added Auto-Assign Auto assign by bot ARM az resource/group/lock/tag/deployment/policy/managementapp/account management-group labels Jul 9, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added Azure CLI Team The command of the issue is owned by Azure CLI team question The issue doesn't require a change to the product in order to be resolved. Most issues start as that labels Jul 9, 2024
@yonzhan
Copy link
Collaborator

yonzhan commented Jul 9, 2024

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

@yonzhan yonzhan added this to the Backlog milestone Jul 9, 2024
@yonzhan yonzhan removed the bug This issue requires a change to an existing behavior in the product in order to be resolved. label Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ARM az resource/group/lock/tag/deployment/policy/managementapp/account management-group Auto-Assign Auto assign by bot Auto-Resolve Auto resolve by bot Azure CLI Team The command of the issue is owned by Azure CLI team question The issue doesn't require a change to the product in order to be resolved. Most issues start as that
Projects
None yet
Development

No branches or pull requests

3 participants