Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accelerator: Extend custom policy definitions - How to survive from ALZ upgrade? #646

Open
1 task done
teemukom opened this issue Oct 6, 2023 · 7 comments
Open
1 task done
Assignees
Labels
Area: Accelerator ⚡ Issues / PR's related to Accelerators Area: Policy 📝 Issues / PR's related to Policy Status: Long Term ⌛ We will do it, but will take a longer amount of time due to complexity/priorities Type: Documentation 📄 Improvements or additions to documentation Type: Enhancement ✨ New feature or request Type: Question / Feedback ❓👂 Further information is requested or just some feedback

Comments

@teemukom
Copy link

teemukom commented Oct 6, 2023

Let us know the feedback or general question

If I would like to extend the customPolicyDefinition.bicep module, how should I upgrade the ALZ to a newer version?

  1. Using the documented (https://github.com/Azure/ALZ-Bicep/wiki/AddingPolicyDefs#how-do-i-extend-the-alz-bicep-custom-policy-definitions-module) way to extend will get overwritten when upgrading the ALZ version
  2. Copying the module to custom-modules (https://github.com/Azure/ALZ-Bicep/wiki/Accelerator#incorporating-modified-alz-modules) would require fixing the file paths in policy definitions

So would like to hear the "correct" way of doing this :)

Code of Conduct

  • I agree to follow this project's Code of Conduct
@Acenl12
Copy link
Contributor

Acenl12 commented Oct 9, 2023

I think this also applies to the alz policies based on ky experience.
And i think i would be a feature request to provide a separate script or pipeline to upgrade alz-bicep without overwriting custom modifications.

What Im thinking of is

  1. creating a temporary directory with the new alz release
  2. Checking which files have modifications by doing a compare
  3. Putting the modified values in a hash table or variable
  4. Sync the temp dir with the new release
  5. Putting back in the modified values from the hash table or variables

And moving forward to make easier to upgrade seperate the parameters from the modules so the modules can be easily upgraded because they don't have any custom values

@jtracey93
Copy link
Contributor

Yup myself and @oZakari have this in our backlog to create more guidance for this with the accelerator and a specific focus on policies.

Stay tuned

@MilesCameron-DMs
Copy link
Contributor

@jtracey93 @oZakari

Assuming these proposed changes to manage policy for ALZ-Bicep and the Accelerator include policy assignment?

I have been looking at this and right now it seems you can't assign built-in or custom policies without introducing a fair bit of new code with the nagging feeling at the back of my head that i will be introducing a breaking change.

From what i can see you cant also scope policy assignment anywhere except at the MG level.

Can you confirm:

  • if these are all on the roadmap
  • rough time-scales - we need to be able to assess whether time needs to be allocated to changing the codebase

More than happy to help if i can.

@MilesCameron-DMs
Copy link
Contributor

MilesCameron-DMs commented Dec 7, 2023

Looking at it, i think it needs:

  • a module for builtin/custom (as suggested)
  • modules for subscription and resource group assignments
  • a parameter file (bicepparam) for managing these - there are too many hard coded vars in the code

Outside of this but related:

  • A better way of handling ALZ-Bicep updates with Accelerator approach so we don't have to hardcode version number on multiple places (i think this is being worked on)
  • The codebase needs to be better modularised. I seen a comment suggesting it was better like this but my experience is that customising it when some of its in a massive bicep file results in uncommenting and messy changes.

@oZakari
Copy link
Contributor

oZakari commented Dec 12, 2023

Hi @MilesCameron-DMs, the current work in regard to this issue does cover both policy definitions and policy assignments. However, it's mostly around how to handle upgrades in the context of the Accelerator. Specifically, with guidance around updating and utilizing the Invoke-PolicyToBicep.ps1. This script already provides a manageable approach to extend policy from a definition, initiative, and assignment perspective. See https://github.com/Azure/ALZ-Bicep/wiki/AddingPolicyDefs for more info. This should give a bit more context for why there are hard-coded values and why they are massive variables and how to update them. After going through that documentation specified previously let me know if that provides a bit more context or if I am off base for what you're referring to, please let me know! :)

From a policy assignment scope perspective, you're correct that we only have a module for deploying custom policies at the management group scope. I think it may be possible for us to add another module for the subscription scope, but we'd probably need to get some additional context and interest in the broader community before we'd go to the extent of setting up a module for policy assignments at the resource group. If possible, could you please create a separate issue for potentially adding these new modules and I can bring up with the broader team?

@MilesCameron-DMs
Copy link
Contributor

@oZakari Thanks for getting back to me.

This was a multi point observation really. I understand the challenge within the Accelerator but the real issue is assigning built-in and/or your own custom policies using ALZ-Bicep. This is essentially a new workflow/bicep module. I started looking at the code, as the suggestion is to clone the current one, and found that its difficult to keep it clean in the context of Accelerator.

That is when i could see that it cant handle subscription assignments which is essential for us and others i am sure.

The resource group not so much but there is the odd requirement where multiple teams are using a shared subscription and the landing zone is viewed as a resource group.

@oZakari
Copy link
Contributor

oZakari commented Dec 13, 2023

Thanks @MilesCameron-DMs for opening up the issue for the additional module. Will bring this up with the broader team.

@oZakari oZakari added Status: Long Term ⌛ We will do it, but will take a longer amount of time due to complexity/priorities Area: Policy 📝 Issues / PR's related to Policy Area: Accelerator ⚡ Issues / PR's related to Accelerators Type: Enhancement ✨ New feature or request Type: Question / Feedback ❓👂 Further information is requested or just some feedback Type: Documentation 📄 Improvements or additions to documentation and removed long-term labels Jul 9, 2024
@oZakari oZakari moved this from In Progress to Planned in Azure Landing Zones - Bicep - Public Roadmap Jul 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Accelerator ⚡ Issues / PR's related to Accelerators Area: Policy 📝 Issues / PR's related to Policy Status: Long Term ⌛ We will do it, but will take a longer amount of time due to complexity/priorities Type: Documentation 📄 Improvements or additions to documentation Type: Enhancement ✨ New feature or request Type: Question / Feedback ❓👂 Further information is requested or just some feedback
Development

No branches or pull requests

5 participants