Is your feature request related to a problem? Please describe.
When writing new initiatives, policyDefinitionGroups must be defined for each referenced groupNames group in the policyDefinitions block. In a scenario where a new policy is added with a previously undefined group name (namely, the group membership is defined in the policyDefinitions but the group is not defined in the groupNames), the initiative deployment will fail.
However, this requirement is not proofed during the "plan" stage. Instead, the plan stage passes (green), the pipeline moves onto the "deploy" stage which notices the discrepancy between the current initiative in Azure (without the new policy) and the updated definition in EPAC (with the new policy). The deployment script then deletes the initiative (and presumably associated assignment) and only upon redeployment will the script fail, with error,
Set-AzPolicySetDefinitionRestMethod: /home/vsts/work/1/s/Scripts/Deploy/Deploy-PolicyPlan.ps1:171
Line |
171 | Set-AzPolicySetDefinitionRestMethod -Definition $entry -A …
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| definition error 400 -- { "error": { "code":
| "InvalidPolicySetDefinitionGroups", "message": "The policy set
| definition 'INITIATIVE' request is invalid. The
| following group names are referenced but do not exist in the policy set:
| 'GROUPNAME'." } }
##[error]PowerShell exited with code '1'.
This leaves the deployed policies in an unhealthy state, where a code revert must be done to restore a healthy configuration.
Describe the solution you'd like
An ideal solution would include a check in the Build-DeploymentPlans.ps1 (or one of its children) script which verifies that all groupNames referenced by policies in the initiative also exist in the policyDefinitionGroups.
Describe alternatives you've considered
Adding --what-if functionality to the Set-AzPolicySetDefinitionRestMethod cmdlet would likely also allow for a solution, however I suspect this will be significantly more effort.
Additional context
To recreate this scenario,
Create a new initiative with any policy and deploy it (no error)
Add the following code block to the policy definition
Is your feature request related to a problem? Please describe. When writing new initiatives,
policyDefinitionGroups
must be defined for each referencedgroupNames
group in thepolicyDefinitions
block. In a scenario where a new policy is added with a previously undefined group name (namely, the group membership is defined in thepolicyDefinitions
but the group is not defined in thegroupNames
), the initiative deployment will fail.However, this requirement is not proofed during the "plan" stage. Instead, the plan stage passes (green), the pipeline moves onto the "deploy" stage which notices the discrepancy between the current initiative in Azure (without the new policy) and the updated definition in EPAC (with the new policy). The deployment script then deletes the initiative (and presumably associated assignment) and only upon redeployment will the script fail, with error,
This leaves the deployed policies in an unhealthy state, where a code revert must be done to restore a healthy configuration.
Describe the solution you'd like An ideal solution would include a check in the
Build-DeploymentPlans.ps1
(or one of its children) script which verifies that all groupNames referenced by policies in the initiative also exist in thepolicyDefinitionGroups
.Describe alternatives you've considered Adding
--what-if
functionality to theSet-AzPolicySetDefinitionRestMethod
cmdlet would likely also allow for a solution, however I suspect this will be significantly more effort.Additional context To recreate this scenario,