Add Aure Policy Metadata Version Support

[CZM89]

AzOps/src/data/template/template.json

Line 90 in 2451859

"Microsoft.Authorization/policyAssignments": "2020-03-01",

During a deployment using Invoke-AzOpsPush for a policy definition we get this error:
New-AzManagementGroupDeployment : 3:52:48 PM - The deployment 'AzOps-microsoft.authorization_policydefinitions-aab-logic-a-16FA' failed with error(s). Showing 1 out of 1 error(s).
Status Message: The property 'version' is not supported in API version '2020-03-01'. Please use API version '2023-04-01' or higher. (Code:UnsupportedApiVersion)

CorrelationId: 6a557bf5-b5ed-4ea4-8ef0-165ff0e56e8a
At C:\a\1\Modules\AzOps\2.4.0\AzOps.psm1:2886 char:21

•                 & $deploymentCommand @parameters
  

•                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

• CategoryInfo : NotSpecified: (:) [New-AzManagementGroupDeployment], Exception
• FullyQualifiedErrorId : Microsoft.Azure.Commands.ResourceManager.Cmdlets.Implementation.NewAzureManagementGroupDeploymentCmdlet

Some more information, in our Policy definition we want to use a property called 'version' that we have nested under metadata. We use these properties for internal management and additional actions.
.....
properties": {
"description": ".",
"displayName": "",
"metadata": {
"category": "",
"validation": "true",
"version": "1.1.1"
},
......

[Jefajers]

Hi @CZM89, thanks for reporting this.

Lets see if I understand your ask.

You would like to use the version property in the metadata field like this:

And if you attempt to do that currently with AzOps you get an error during Push like below:

Just like the error points out currently AzOps is utilizing a API version 2020-03-01 which does not support this property (first API version with support 2020-09-01) and the consequence of that is not visible in validate pipeline with whatif $true which succeeds, once a push with what if is set to $false it fails.

I will add this item as a feature request.

[JenniferKlaveren]

Hi,
my colleague who originally posted this question has gone on a holiday and asked me to keep track of the ticket. I just want to point out that the issue is not related to the metadata version field, but one step back in the actual policy file template. In the metadata is actually the only place where it gets automatically ignored. We mean the following ones:

Apologies for the confusion, I guess at the time of posting my colleague thought the metadata field version was included in the problem, but since then we have found out that it's not.

[Jefajers]

Hi @JenniferKlaveren, the version and versions properties referenced are not something available to manipulate/utilize at this point in time from the resource provider.

This behavior is not related to AzOps but a constraint of the resource provider.

Re-produce the error by following the referenced link and test out the API PUT operation in Azure and attempt to add the properties.version setting. This will result in The policy definition: 'xyz' has an invalid version value: '1.0.1'. Changing the value of the 'version' property is not yet supported in this environment. Please remove the property from the request body and try again.

However as mentioned in my earlier response the properties.metadata.version is possibel to set at the resource provider level but currently AzOps is utilzing an older API version which is probhiting that usage. The properties.metadata.version situation we can resolve in AzOps by bumping the API version.

[bkeyser]

Hi @Jefajers ... we have been running into this same issue as the API version is '2020-03-01'. After a pull the role definition has been updated to include the version information from the current API version of '2023-04-01'. With a modification to the role definition and a subsequent push ARM fails with a similar error mentioned in the original post

New-AzManagementGroupDeployment: 21:53:46 - The deployment 'AzOps-microsoft.authorization_policydefinitions-deny-...' failed with error(s). Showing 1 of 1 error(s).  Status Message:  The property 'version' is not supported in API version '2020-03-01'.  Please use API Version '2023-04-01' or higher. (Code: UnsupportedApiVersion) CorrelationId: ...

I think your suggestion of bumping the API version might help to address this issue. I believe the title of the issue suggests a different problem (or the one we are experiencing is different ;-) ). I am learning more about AzOps and was wondering about the effort involved in modifying the API version to '2023-04-01'?

[CZM89]

Hi @Jefajers , As my colleague stated I was away for a while. I'm back and and although I agree that indeed this is also an issue with the resource provider (not being able to manipulate that property even with using the correct API version) it would really be helpful to not have the API version hardcoded in the AzOps module, but rather make that a usable parameter when we use Invoke-AzOpsPush. I hope this ends up on a roadmap somewhere. 🤞

[Jefajers]

Hi @Jefajers ... we have been running into this same issue as the API version is '2020-03-01'. After a pull the role definition has been updated to include the version information from the current API version of '2023-04-01'. With a modification to the role definition and a subsequent push ARM fails with a similar error mentioned in the original post

New-AzManagementGroupDeployment: 21:53:46 - The deployment 'AzOps-microsoft.authorization_policydefinitions-deny-...' failed with error(s). Showing 1 of 1 error(s).  Status Message:  The property 'version' is not supported in API version '2020-03-01'.  Please use API Version '2023-04-01' or higher. (Code: UnsupportedApiVersion) CorrelationId: ...

I think your suggestion of bumping the API version might help to address this issue. I believe the title of the issue suggests a different problem (or the one we are experiencing is different ;-) ). I am learning more about AzOps and was wondering about the effort involved in modifying the API version to '2023-04-01'?

Hi @bkeyser, weclome. The updated api version that this issue relates to, has been addressed recently in AzOps 2.6.1 and is referenced in PR #872. If you are running 2.6.1 and are seeing some new issues or still see this behavior don't hesitate to open a new issue or re-open this one.