Terraform order of ip filter rules for IoT Hub

Question

I want to deploy multiple azure cloud resources with terraform. My problem is with the terraform script for an azure IoT Hub, exspecially the ip restriction rules. According to the documentation I can do something like this

 resource "azurerm_iothub" "iothubname" {
  name                = "somename"
  resource_group_name = azurerm_resource_group.someresourcegroup
  location            = azurerm_resource_group.somelocation

  sku {
    name     = "B2"
    capacity = "2"
  }

  fallback_route {
    enabled = true
  }



ip_filter_rule {
    action = "Accept"
    ip_mask ="some_ip_range_1"
    name = "some_name_1"
}



 ip_filter_rule {
      action = "Accept"
        ip_mask ="some_ip_range_2"
        name = "some_name_2"   }



ip_filter_rule {
      action = "Accept"
        ip_mask ="some_ip_range_3"
        name = "some_name_3"
  }



 ip_filter_rule {
      action = "Reject"
        ip_mask ="0.0.0.0/0"
        name = "everything_else"
  }

}

Everything works fine, ecept that the ordering of the ip rules is not the same as above and in my case I definitely want the last rule to be the the one with the lowest priority on azure. Azure IoT hub applies the filter rules in order.

How can I enforce a certain ordering of ip filter?

Answer 1

You can try to use dynamic blocks

https://www.terraform.io/docs/configuration/expressions/dynamic-blocks.html

File main.tf

resource "azurerm_iothub" "iothubname" {
  name                = "somename"
  resource_group_name = azurerm_resource_group.someresourcegroup
  location            = azurerm_resource_group.somelocation

  sku {
    name     = "B2"
    capacity = "2"
  }

  fallback_route {
    enabled = true
  }

  dynamic "ip_filter_rule" {
  for_each = var.ip_filter_rule_list
    content {
      action = ip_filter_rule.value.action
      ip_mask = ip_filter_rule.value.ip_mask
      name = ip_filter_rule.value.name
    }
  }
}

File variables.tf

variable "ip_filter_rule_list" {
type = list
default = []
}

Update

Bug is fixed in terraform provider azurerm v2.57.0

https://github.com/terraform-providers/terraform-provider-azurerm/pull/11390