-
Notifications
You must be signed in to change notification settings - Fork 514
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
Comments
I think this also applies to the alz policies based on ky experience. What Im thinking of is
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 |
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 |
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:
More than happy to help if i can. |
Looking at it, i think it needs:
Outside of this but related:
|
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? |
@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. |
Thanks @MilesCameron-DMs for opening up the issue for the additional module. Will bring this up with the broader team. |
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?
So would like to hear the "correct" way of doing this :)
Code of Conduct
The text was updated successfully, but these errors were encountered: