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

Firewall app rules #2532

Merged
merged 18 commits into from
Jan 4, 2019
Merged

Firewall app rules #2532

merged 18 commits into from
Jan 4, 2019

Conversation

hbuckle
Copy link
Contributor

@hbuckle hbuckle commented Dec 18, 2018

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?

@ghost ghost added the size/XXL label Dec 18, 2018
@katbyte
Copy link
Collaborator

katbyte commented Dec 18, 2018

@hbuckle,

here is an example of multiple ConflictsWith

@hbuckle
Copy link
Contributor Author

hbuckle commented Dec 18, 2018

@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
Copy link
Collaborator

katbyte commented Dec 19, 2018

@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 🙂

@ghost ghost added the documentation label Dec 20, 2018
@hbuckle
Copy link
Contributor Author

hbuckle commented Dec 21, 2018

@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

@ghost ghost removed the waiting-response label Dec 21, 2018
@katbyte
Copy link
Collaborator

katbyte commented Dec 24, 2018

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
Copy link
Contributor Author

hbuckle commented Dec 31, 2018

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

@ghost ghost removed the waiting-response label Dec 31, 2018
@katbyte
Copy link
Collaborator

katbyte commented Dec 31, 2018

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

Copy link
Collaborator

@katbyte katbyte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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 🙂

}

err = future.WaitForCompletionRef(ctx, client.Client)
if err != nil {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor these lines could be combined:

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

@hbuckle
Copy link
Contributor Author

hbuckle commented Jan 2, 2019

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

@ghost ghost removed the waiting-response label Jan 2, 2019
Copy link
Collaborator

@katbyte katbyte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for all the updates @hbuckle LGTM now 🙂

@katbyte
Copy link
Collaborator

katbyte commented Jan 4, 2019

tests pass:
screen shot 2019-01-03 at 16 17 58

@katbyte katbyte merged commit 577b2f7 into hashicorp:master Jan 4, 2019
katbyte added a commit that referenced this pull request Jan 4, 2019
@katbyte katbyte added this to the 1.21.0 milestone Jan 4, 2019
@ghost
Copy link

ghost commented Mar 5, 2019

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!

@ghost ghost locked and limited conversation to collaborators Mar 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants