No way to delete a Firewall Policy Rule Collection Group in Bicep/ARM

[ChristopherGLewis]

Is there any way to delete an Rule Collection Group in ARM/Bicep??? - I've added an issue (#17989), but thought starting a discussion may help

I'm in the process of creating bicep templates for Azure Firewall Policies and have encountered what I consider a bug in the RP/API for Rule Collection Groups.

If I create an Azure Firewall Policy in code and add a rule collection group to it if I ever remove that rule collection group it does not get deleted and there's no way to delete it in Bicep/ARM.

The problem is that parent/child relationship of the Policy to Rule Collection Groups is only defined in the RCG, not the policy.

Create two RCGs

// ------------------------------------------------------------
// Get the FW policy
// ------------------------------------------------------------
resource azFwPol 'Microsoft.Network/firewallPolicies@2024-05-01' existing = {
  name: fwPolicyName
}

// ------------------------------------------------------------
// add RuleCollectionGroup 1
// ------------------------------------------------------------
resource azFwRCG1 'Microsoft.Network/firewallPolicies/ruleCollectionGroups@2024-05-01' = {
  name: 'Rule1'
  parent: azFwPol
  properties: {
    priority: ruleCollectionGroupPriority
    //ruleCollections: ruleCollections
  }
}

// ------------------------------------------------------------
// add RuleCollectionGroup 2
// ------------------------------------------------------------
resource azFwRCG2 'Microsoft.Network/firewallPolicies/ruleCollectionGroups@2024-05-01' = {
  name: 'Rule2'
  parent: azFwPol
  properties: {
    priority: ruleCollectionGroupPriority
    //ruleCollections: ruleCollections
  }
}

Remove RCG 1 - but there's no way to delete Rule1

// ------------------------------------------------------------
// Get the FW policy
// ------------------------------------------------------------
resource azFwPol 'Microsoft.Network/firewallPolicies@2024-05-01' existing = {
  name: fwPolicyName
}

// ------------------------------------------------------------
// add RuleCollectionGroup 2
// ------------------------------------------------------------
resource azFwRCG2 'Microsoft.Network/firewallPolicies/ruleCollectionGroups@2024-05-01' = {
  name: 'Rule2'
  parent: azFwPol
  properties: {
    priority: ruleCollectionGroupPriority
    //ruleCollections: ruleCollections
  }
}

Incremental vs Complete.

A potential solution is to use a complete Resource Group deployment; however, with the Azure Firewall, this becomes problematic since the Azure Firewall is required to be in the same Resource Group as the network it's in. I haven't looked at a separate RG just for policies, but that could be a solution, but not ideal.

Better Solution

A better solution would be to have the AzFWPolicy have a list of RGC's and have the removal of an RCG from that list result in that RCG being deleted. This is more logical since a RCG can't exist as an Azure object on its own.

[slavizh]

Use deployment stacks https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-stacks?tabs=azure-powershell

[ChristopherGLewis]

Well, that only works if you can deploy everything with Deployment Stacks. My specific example was for policies that were created outside of Stacks.

[slavizh]

in such case there is no other option. My recommendation is to use deployment stack and restrict access to avoid someone adding resources outside of your stack.

[marsontret]

@ChristopherGLewis I heard you talk about this issue on the most recent bicep community call. I've done a quick search and this looks to be documented behaviour! So, the advice to use Stacks or Complete mode is sound - although the documentation says: "Complete mode is not recommended. If you wish to perform deletes with Bicep or ARM template deployments, use Deployment stacks."

Your issue resonated with me because iirc storage Blob containers behave the same way. In fact, I don't think even Complete mode makes a difference there, unlike firewallPolicies.

An alternative approach to deploymentStacks is deploymentScripts. With a script you can write your own logic to deploy, amend or delete the resource. I've used it as a fall back many a time. Azure has many idiosyncrasies!

With regard to bicep specifically, and how it handles this, we can compare it to terraform. Terraform typically deletes and recreates resources it cannot update to match your config. So if you remove your policy from terraform and it can't simply delete them using the RP API it will recreate the resource to match the config! This is effectively the pattern you want to replicate in your deploymentScript.

[Edit: Slight correction - the tf behaviour I described above relates to property changes on resources. It's actually tf state that would come into play here. Basically, the behaviour would be the same as if you used Stacks 😅]

[a-ariff]

You're not doing anything wrong — ARM incremental won't remove child resources just because you stop declaring them. A few ways that do work:

A) Complete mode at the policy scope: deploy a template that omits the ruleCollectionGroup, and set the deployment to Complete. Azure will reconcile and delete it.

B) Explicit delete via CLI in a deploymentScript:
az network firewall policy rule-collection-group delete
--name
--policy-name
--resource-group

C) Conditional remove: set the RCG behind a condition and deploy with Complete mode when you want it gone.

I usually go A for IaC purity; B is great when you can't change mode. Shout if you want a minimal Bicep sample for either route.