Export-AzPolicyResources doesn't extract in the same format as Sync-ALZPolicies

[krallsm]

Describe the bug
Export-AzPolicyResources doesn't extract in the same format as Sync-ALZPolicies

To Reproduce
If you run Export-AzPolicyResources and copy as the documentation instructs, when you go to run Sync-ALZPolicies, there are many file changes that are unnecessary. Both of these scripts are intended for bringing policies from a source into "EPAC format".

Expected behavior
It would be expected that both of these scripts exported to the same format and when used in conjunction with each other that unnecessary file changes wouldn't be performed.

Screenshots
No screenshots, but one easy to observe difference is that Sync-ALZPolicies includes no schema in it's output for policysetdefinitions and policydefinitions, while Export-AlzPolicyResources does. The way the assignments are constructed is also just completely different from each other.

EPAC Version
10.8.1 (Latest)

I know that these scripts were designed by different people at the very least, but it's unclear to me where some of these modifications SHOULD be made. If Export-AlzPolicyResources isn't really used outside of this project for exporting resources, I think it's entirely appropriate to bring these two scripts more in alignment with each other to assist with Integrating with ALZ policies. NOT doing these things could also impact the accessibility of this project to certain admins or engineers seeking to implement EPAC into their organizations.

[anwather]

Thanks for the feedback - just some background on how this works - when you run Sync-ALZPolicies it goes out to the Enterprise scale repository and pulls in the raw JSON files. It then splits them up into initiatives and policies sorted by category. The assignment files don't come from this repo - they are manually maintained and come from the EPAC module itself.

There are a couple of reasons for this - the ALZ repo contains the assignments but doesn't specify the scopes of deployment - as well as this they also include RBAC assignments in there and use a generic ARM template to deploy which EPAC doesn't understand. Because of this the process for updating those assignments involves deploying the ALZ to an environment, running an export and then manually updating the assignment files to go into the module.

The assignment files are created in this way because I wanted to group them by scope of deployment e.g. everything going to platform management group is together in one file - I've looked at splitting it out to individual files (as the export does) but it is a lot messier - if you have any ideas on how this could be grouped would be good. Also I must remove and replace all the parameter values and put comments in to highlight what each parameter does.

What I have had some customers do is after they have deployed ALZ (by accelerator) - they use an Export-AzPolicyResources and then a Sync-ALZPolicies to get the assignments - and then use the values in the exported assignments to update the module formatted assignments - it makes it easier to maintain / read.

With the missing schema from the definitions, I can always add that in if it helps.

[krallsm]

yea, I understand the reasoning a bit, I've played around a little bit to see if there was an "easy" fix and recognized a lot of what you're mentioning here.

My brain wants to think there's a way to translate the ARM templates into EPAC, so it can curate the assignments, rather than being manually maintained. I think someone in another issue somewhere, may have mentioned this as well. I know the Enterprise-Scale repo doesn't have the data easily accessible for the scope, but the Azure Landing Zones Library, does. (https://github.com/Azure/Azure-Landing-Zones-Library/tree/main/platform/alz). I wish it was evident where the true source of truth was, as a lot of things in the general Microsoft Azure repos with policies pull from Enterprise-Scale and not the AZL Zones Library. It does look plausible to me that Enterprise-Scale could pull from the AZL Zones library itself, which would make that library a good candidate for this repo as well, in my opinion, but there easily could be something I'm overlooking here as well. There's no "official" indication I've seen so far as to what is "right" here yet.

Adding the missing schema to the definitions would definitely be helpful I think. I did a little bit of playing around here as well, and I just didn't find the time to do what I really really wanted in terms of making the schema extra dependable and reliable, but at least adding it in there would provide at least some structure to the files.

I've considered dedicating some personal time to this issue in particular, but if someone with more experience in this repo is already working on it, I don't want to necessarily bother because I'm still getting familiar with the repo/module in general and while I believe myself capable, I want to be extra sure that any changes I'd propose are in alignment with y'alls goals and wishes. It'll also just take me longer to implement because I don't quite have "work" time I can dedicate to this at the moment.

For what it's worth as well, I really like how you've compiled the assignments into less files. There's just more risk of mismatching parameters between environments for us shifting to something like that because you can only dedicate one assignment file per PAC scope if you have differing tenants. That just makes it easier for us to have many files and only create separate files if there's a need to differentiate the parameters per tenant. (like la workspace id's and subscriptions) Seeing the validity in both methods there to me, makes it a little difficult to choose trying to fix it in one way or another for these scripts (Sync-ALZPolicies and Export-AzPolicyResources)

[krallsm]

Just saw this issue as well today that might be similar to how Sync-ALZPolicies and Export-AzPolicyResources is producing it's files: #888 - neither of the scripts here struggles to get them, and when a schema is declared it follows the schema correctly, but the data fields like to switch around when they're not declared in the schema. If they didn't switch around, this would eliminate most if not all of the unnecessary file changes that I mention here once the schema field is aligned between the two scripts.