Make IPGroup Firewall Policy links not conflict with Deployment Stack Policy

[ld0614]

Is your feature request related to a problem? Please describe. Deploying a IP Group via a deployment stack on its own is a joy and works really well. Unfortunately when you start using the IP Group with a Firewall Policy issues start to emerge. It appears that when a policy is a assigned a IP group it attempts to write a reference to the Azure Policy back onto the IP Group using the field firewallPoicies:

As this is a write operation to the IP Group outside of the Deployment Stack this causes a conflict when the Deployment stack policy is set to Deny updates.

This gets even worse when a Firewall is assigned the Policy as failing to update the reference on the IP Group causes the firewall policy to enter a failed provisioning state which causes the firewall into a failed provisioning state. This then seems to cause a self-referencing loop so that even if you disable the deny policy the IP Groups will never update correctly which, as they are a dependency for the firewall policy, means that the firewall policy will never update correctly and therefore the only approach I was able to find was to delete the firewall and redeploy the entire stack.

While this was possible in a test environment deleting the primary firewall and waiting for reprovisioning (potentially several hours of downtime) would not be considered ideal in a production environment

Describe the solution you'd like Ideally IP Groups should not be updated by the Azure Firewall Policy or at least this should be easily bypassed without impacting the Deny on updating the actual IP Group Values

Describe alternatives you've considered I initially excluded the following actions from the Deployment Stack:

• Microsoft.Network/ipGroups/join/action
• Microsoft.Network/ipGroups/write However Microsoft.Network/ipGroups/write is also used by users to update the IP Addresses in an IP Group, effectively bypassing the deployment stack protection policy for IP Groups entirely.

I also attempted to bypass the deployment account from the deployment stack policy however while this seemed to work for policies not attached to Firewalls, it doesn't appear to work correctly when Firewalls are provisioned. Maybe there is a system account making the update to the IP Group but I was unable to identify the account needed to bypass.

Additional context I'm attempting to build a deployment stack to manage the core network vWAN and Firewall solution, enabling a full IaC test and deployment platform for the critical network assets.

[azcloudfarmer]

Hi @ld0614 - thank you for the detail. Can you share the template for us to repro the behavior on our end? Thanks!

[ld0614]

HI @azcloudfarmer I've created a minimum repo https://github.com/ld0614/IPGroupIssue. You should just be able to run Deploy.ps1 after logging into a suitable Azure subscription to see the issue. There are ways that this issue becomes more complicated when combined with DevOps and the Azure Firewall/vWAN but I wanted to keep the repro as simple as possible initially.

[azcloudfarmer]

Hi @ld0614 - apologies for the delay. We've confirmed the repro on our end and will be working with the Network team to see what our options are here. I will keep you posted with updates on this thread. Our tracking item for reference: https://msazure.visualstudio.com/One/_workitems/edit/26057697

[ld0614]

Thanks for the update @azcloudfarmer I hope that the fix is easy to implement

[snarkywolverine]

Hi @ld0614 - can you try this again to see if it's still an issue for you? @Xynoclafe checked in a fix for this that has recently rolled out to most regions, including UK South.

[snarkywolverine]

I'm going to close this, since the issue should be resolved in all regions. Feel free to reactivate if you are seeing a different behavior.