Firewall app rules

[hbuckle]

Adds support for Azure firewall application rules. I'll follow up with the docs shortly
I wasn't sure how to get the ConflictsWith to work with lists of more than one element - any pointers?

[katbyte]

@hbuckle,

here is an example of multiple ConflictsWith

[hbuckle]

@katbyte that example and all the others i've seen are for lists with MaxItems: 1 - this list could have multiple items, so what would I use for the .0. part ?

[katbyte]

@hbuckle,

It will work just fine. Because your saying that property a conflicts with property b.0 or b.0.c it does not matter how many items are in list b. There will always be first, 0, element 🙂

[hbuckle]

@katbyte the requirement here is that properties of items in the list need to conflict with each other, but there could be multiple items in the list.
So this example config should be valid

resource "azurerm_firewall_application_rule_collection" "test" {
  name                = "acctestarc"
  azure_firewall_name = "${azurerm_firewall.test.name}"
  resource_group_name = "${azurerm_resource_group.test.name}"
  priority            = 100
  action              = "Allow"

  rule {
    name = "rule1"

    source_addresses = [
      "192.168.2.1",
    ]

    target_fqdns = [
      "*.microsoft.com",
    ]

    protocol {
      port = 8443
      type = "Https"
    }

    protocol {
      port = 8080
      type = "Http"
    }
  }

  rule {
    name = "rule2"

    source_addresses = [
      "10.0.0.0/16",
    ]

    fqdn_tags = [
      "test",
    ]
  }
}

but using rule.0. produces the error Error: azurerm_firewall_application_rule_collection.test: "rule.1.fqdn_tags": conflicts with rule.0.target_fqdns - so instead of .0. I need something that refers to the current item in the list

[katbyte]

Ah sorry @hbuckle, i misunderstood.

unfortunately i think they best way is to just check that in the create/update function and return an error if there is there is a conflict. CustomizeDiff could also be used to catch these errors during a plan, however it won't work for interpolated values so we are avoiding it at the moment.

[hbuckle]

OK I've added the validation into expandArmFirewallApplicationRules
I'm not sure if that's the best place for it as it only triggers when the rules are created, not during the plan phase

[katbyte]

Thanks @hbuckle, its not ideal but its all we can do at the moment.

[katbyte]

@hbuckle,

Thanks for the updates, I have left some mostly minor/stylistic comments inline. However it does appear some of your test checks are invalid. Other then that this is looking pretty good and once these issues are fixed up we should be good to merge 🙂

[katbyte]

minor these lines could be combined:

		if err = future.WaitForCompletionRef(ctx, client.Client); err != nil {

[hbuckle]

I think I've fixed up all the test attributes, and also updated the utility functions

[katbyte]

Thank you for all the updates @hbuckle LGTM now 🙂

[katbyte]

tests pass:

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!