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

Support for rule_collection as resources for azurerm_firewall_policy_rule_collection_group #16586

Open
1 task done
HSoulat opened this issue Apr 28, 2022 · 5 comments
Open
1 task done

Comments

@HSoulat
Copy link

HSoulat commented Apr 28, 2022

Is there an existing issue for this?

  • I have searched the existing issues

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Hi,

For now all application, network and nat rules collections must be listed as arguments in a single azurerm_firewall_policy_rule_collection_group resource. This could lead to a very long resource configuration.

resource "azurerm_firewall_policy_rule_collection_group" "example" {
  name               = "example-fwpolicy-rcg"
  firewall_policy_id = azurerm_firewall_policy.example.id
  priority           = 500
  application_rule_collection {
    name     = "app_rule_collection1"
    priority = 500
    action   = "Deny"
    rule {
      name = "app_rule_collection1_rule1"
      protocols {
        type = "Http"
        port = 80
      }
      protocols {
        type = "Https"
        port = 443
      }
      source_addresses  = ["10.0.0.1"]
      destination_fqdns = [".microsoft.com"]
    }
  }

  network_rule_collection {
    name     = "network_rule_collection1"
    priority = 400
    action   = "Deny"
    rule {
      name                  = "network_rule_collection1_rule1"
      protocols             = ["TCP", "UDP"]
      source_addresses      = ["10.0.0.1"]
      destination_addresses = ["192.168.1.1", "192.168.1.2"]
      destination_ports     = ["80", "1000-2000"]
    }
  }

  nat_rule_collection {
    name     = "nat_rule_collection1"
    priority = 300
    action   = "Dnat"
    rule {
      name                = "nat_rule_collection1_rule1"
      protocols           = ["TCP", "UDP"]
      source_addresses    = ["10.0.0.1", "10.0.0.2"]
      destination_address = "192.168.1.1"
      destination_ports   = ["80", "1000-2000"]
      translated_address  = "192.168.0.1"
      translated_port     = "8080"
    }
  }
}

Like for other resources, theses arguments could be created as separate resources. This could allow to create more readable configuration file.

New or Affected Resource(s)/Data Source(s)

azurerm_firewall_policy_rule_collection_group, application_rule_collection, network_rule_collection, nat_rule_collection

Potential Terraform Configuration

resource "azurerm_firewall_policy_rule_collection_group" "example" {
  name               = "example-fwpolicy-rcg"
  firewall_policy_id = azurerm_firewall_policy.example.id
  priority           = 500
}

resource "application_rule_collection" "app_example" {
  azurerm_firewall_policy_rule_collection_group_id = azurerm_firewall_policy_rule_collection_group.example.id
  name     = "app_rule_collection1"
  priority = 500
  action   = "Deny"
  rule {
    name = "app_rule_collection1_rule1"
    protocols {
      type = "Http"
	  port = 80
	}
	protocols {
	  type = "Https"
	  port = 443
	}
    source_addresses  = ["10.0.0.1"]
    destination_fqdns = [".microsoft.com"]
  }
}

resource "network_rule_collection" "net_example" {
  azurerm_firewall_policy_rule_collection_group_id = azurerm_firewall_policy_rule_collection_group.example.id
  name     = "network_rule_collection1"
  priority = 400
  action   = "Deny"
  rule {
    name                  = "network_rule_collection1_rule1"
    protocols             = ["TCP", "UDP"]
    source_addresses      = ["10.0.0.1"]
    destination_addresses = ["192.168.1.1", "192.168.1.2"]
    destination_ports     = ["80", "1000-2000"]
  }
}

resource "nat_rule_collection" "nat_example" {
  azurerm_firewall_policy_rule_collection_group_id = azurerm_firewall_policy_rule_collection_group.example.id
  name     = "nat_rule_collection1"
  priority = 300
  action   = "Dnat"
  rule {
    name                = "nat_rule_collection1_rule1"
    protocols           = ["TCP", "UDP"]
    source_addresses    = ["10.0.0.1", "10.0.0.2"]
    destination_address = "192.168.1.1"
    destination_ports   = ["80", "1000-2000"]
    translated_address  = "192.168.0.1"
    translated_port     = "8080"
  }
}

References

No response

@sfinke0
Copy link

sfinke0 commented May 4, 2022

Hi @HSoulat,

even though I would like to see this feature implemented as well, I don't think it is possible as of now. Looking through the documentation of the Azure API and the Azure Go SDK the required API endpoints for this feature simply do not seem to exist (yet?). So currently there is no other way to create rule collections as separate resources in conjunction with a Firewall Policy.

What I noticed however is that you can manage azurerm_firewall_network_rule_collection, azurerm_firewall_application_rule_collection, azurerm_firewall_nat_rule_collection from Terraform if you use a Standard Firewall with Firewall rules (classic) instead of a Firewall Policy.

regards
Sebastian

@lemmensdr
Copy link

Hi, Is this still the case? I see now with azure cli you can split the creation between rule collection group (the rule collection itself) and rule collection group collection (the network/application group + all the rules). The
azurerm_firewall_policy_rule_collection_group is now very difficult to handle when you try to build it dynamically.

Best regards

@NikolaiKleppe
Copy link

We are also seeing a need for this functionality. Managing firewall rules at scale with one (or a few) very large azurerm_firewall_policy_rule_collection_group's is quite troublesome, even when it's with code. Please look into this

@lemmensdr
Copy link

The use of IP Groups makes it little bit easier where you create a set of default rules with ip groups. And you only change the ip groups when new ip ranges need to be added or deleted. This way you don't touch the firewall config when changes need to be done.

@jr8279
Copy link

jr8279 commented Jun 13, 2023

I agree that not having each rule collection as an individual resource is frustrating and limiting to our ability to manage a large number of rule collections at scale. But this is not a limitation of how Terraform deploys the rule collection; rather a limitation of how Microsoft has designed the Rule Collection Groups.

We have been able to get around some of this limitation by breaking the rule collections into individual yaml files and then joining the files and using a dynamic block to loop through the list of rule collections. The piece that we are unable to overcome is that the rule collections are in Azure Rule Collection Group, and thus in the Terraform State file, as an ordered list. This means that making an update to a rule in the middle of the list results in every rule below it being modified. To help reduce the potential impact of a reorder, we have opted to order the list by priority number rather than by rule name.

This ordered list approach by Microsoft also means that rules within a rule collection are also subject to reordering if updates are made. It is unfortunate that Microsoft has chosen this path for firewall rule management. I even had a Microsoft Support rep admit that the way Classic Rules are managed is a more efficient way to manage a large number of rules. Microsoft went with a Azure Portal UI focus for managing the firewall rule collection groups, which might work for smaller organizations. But this approach makes it extremely difficult to manage IaC at a large scale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants