Azure / enterprise-azure-policy-as-code

Enterprise-ready Azure Policy-as-Code (PaC) solution (includes Az DevOps pipeline)
https://azure.github.io/enterprise-azure-policy-as-code/
MIT License
403 stars 206 forks source link

Check groupNames against policyDefinitionGroups during plan #660

Closed benjaminpieplow closed 1 month ago

benjaminpieplow commented 1 month ago

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,