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
432 stars 238 forks source link

question: suggested approach for managing different log analytics IDs within an archetype #532

Closed kewalaka closed 6 months ago

kewalaka commented 7 months ago

I have a situation where I have a CAF-aligned management group structure (imagine something like 'corp' and 'online', and a request to separate log analytics workspace destinations per SLDC environment (yes, I know, LAWs should be centralised as much as possible).

As per CAF, we want to avoid creating an MG structure the follows the SLDC (dev,test,prod).

The only way I can see to do it at the moment is to copy the entire sets of policies and use scopes to target the appropriate subs (e.g. based on their name, as they follow a convention that includes the environment in the sub name)

This doesn't seem the right way, as then you're basically back to separating policies based on environments - you're just doing it in EPAC rather than via a policy assignment to an environment-specific MG.

I feel like I'm missing an obvious solution & wondering if there's a better way (can parameterSelectors help here, or if is a candidate to look at a CSV approach) ?

The benefit I can see to separating is based on environment is it at least provides an opportunity to test potentially disruptive DINE policies before deploying to production workloads, but then, that's usually fixed by having a test environment dedicated for Policy changes.

Would appreciate some guidance on how best to proceed, both on the LAW issue, and the testing approach.

anwather commented 7 months ago

This is what I would do:-

  1. Test environment or scope for policy testing - great idea
  2. Just create multiple assignments files for the assignments which have different LAWs. I normally put these into different folders under the policyAssignments folder so I can visually tell them apart. Then just adjust parameters and scope within there.
  3. As much as possible I try not to replicate policy definitions or set definitions for each environment and control everything via the assignment and its scope and parameters.