Policy refactoring with automation and testing

[krowlandson]

Overview/Summary

This PR makes a fundamental change to the how we manage and test custom policies implemented as part of Azure landing zones.

This PR fixes/adds/changes/removes

1. Adds a new resource library containing individual policy definition and policy set definition resources as individual files
2. Adds a Bicep template used to programmatically generate a new policies.json file for the eslzArm Portal deployment
3. The new policies.json template is now designed to universally work across AzureCloud, AzureChinaCloud and AzureUsGovernment clouds
4. Adds new GitHub Action to automatically regenerate policies.json when relevant changes are detected in a PR
5. Adds new GitHub Action to perform static code analysis (linting) of the new src folder (also scans eslzArm folder but for reporting only)
6. Adds a new GitHub Action to perform automated testing of the eslzArm deployment, including a complete deployment and tear-down
7. Adds an updated version of the original EnterpriseScaleLibraryTools PowerShell module from the Terraform implementation, now rebranded as Alz.Tools and extended to include new functionality needed for broader use (will be re-usable for Terraform and Bicep implementations)
8. Adds a new GitHub Action to keep the Alz.Tools module up to date with the latest API versions
9. Includes minor (primarily cosmetic) updates to the eslzArm deployment to improve maintainability and control whilst running programmatically
10. Update elements in Portal UI definition to match the parameters set by their output for easier maintenance
11. Added logic to customize the Portal UI questions based on target Cloud environment, to improve support for AzureChinaCloud (pending update to MG scope deployment) and AzureUSGovernment
12. Improve consistency across deployment names and update to use alz- prefix instead of EntScale-
13. Update description field in emailContactAsc parameter across Cloud environments for Deploy-MDFC-Config Policy Assignment

Breaking Changes

None identified

Testing Evidence

AzureCloud

See test pipelines in GitHub Actions.

policies.json for AzureChinaCloud

Testing evidence to follow

policies.json for AzureUsGovernment

Testing URLs

n/a

As part of this Pull Request I have

• [x] Checked for duplicate Pull Requests
• [ ] Associated it with relevant issues, for tracking and closure.
• [x] Ensured my code/branch is up-to-date with the latest changes in the main branch
• [x] Performed testing and provided evidence.
• [x] Updated relevant and associated documentation.
• [ ] Updated the "What's New?" wiki page (located: /docs/wiki/whats-new.md)

[faister]

@krowlandson I'll have a go with testing this in Azure China, will reach out when I have questions

[matt-FFFFFF]

I have one concern that we are using a Bicep data structure to store the configuration for the public/mc/ff policies.

This should be in a common data format like JSON or YAML.

I understand there is a feature request in the Bicep team for changes to a function Azure/bicep/issues/3816#issuecomment-1191230215 but they have not committed to producing this. As a workaround to this I would like us to store the data as JSON/YAML, then convert this to Bicep in the absence of working bicep function. This way we can start on the journey to have a machine readable definition for ALZ.

[jtracey93]

I have one concern that we are using a Bicep data structure to store the configuration for the public/mc/ff policies.

This should be in a common data format like JSON or YAML.

I understand there is a feature request in the Bicep team for changes to a function Azure/bicep/issues/3816#issuecomment-1191230215 but they have not committed to producing this. As a workaround to this I would like us to store the data as JSON/YAML, then convert this to Bicep in the absence of working bicep function. This way we can start on the journey to have a machine readable definition for ALZ.

This is a good idea. However, the term "workaround" doesn't sit well with me.

Being honest, today, do we actually find ourselves updating the list of policies for clouds? It's more updating existing policies and the rule definitions of them.

Also, by templating now and then reverting back to bicep at a later date, if the feature is added, do we think it is worth the additional engineering effort?

If so, we may need you to pick this up as @krowlandson is going to be OOF over the next few weeks at different times. Or do we think we can merge this and then evolve from there with another PR later to look at templating option?

This may be easier for all of us to discuss on a call 🙂 let me know if you think so and I'll find us a slot