Terraform-provider-aws: [WAFv2] Resource aws_wafv2_web_acl is recreated on any changes to the rules

Created on 25 Jun 2020  ·  9Comments  ·  Source: hashicorp/terraform-provider-aws

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 other comments that do not add relevant new information or questions, 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

Terraform Version

Terraform v0.12.26
provider.aws v2.67.0

Affected Resource(s)

aws_wafv2_web_acl

Terraform Configuration Files

resource "aws_wafv2_web_acl" "default" {
  name        = "webacl-example"
  scope       = "CLOUDFRONT"

  default_action {
    block {}
  }

  rule {
    name     = "AWS-AWSManagedRulesSQLiRuleSet"
    priority = 0

    override_action {
      count {}
    }

    statement {

      managed_rule_group_statement {
        name        = "AWSManagedRulesSQLiRuleSet"
        vendor_name = "AWS"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "AWS-AWSManagedRulesSQLiRuleSet"
      sampled_requests_enabled   = true
    }
  }

  rule {
    name     = "AWS-AWSManagedRulesCommonRuleSet"
    priority = 1

    override_action {
      count {}
    }

    statement {

      managed_rule_group_statement {
        name        = "AWSManagedRulesCommonRuleSet"
        vendor_name = "AWS"

        excluded_rule {
          name = "GenericLFI_QUERYARGUMENTS"
        }
        excluded_rule {
          name = "GenericLFI_URIPATH"
        }
        excluded_rule {
          name = "GenericLFI_BODY"
        }
        excluded_rule {
          name = "SizeRestrictions_BODY"
        }
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "AWS-AWSManagedRulesCommonRuleSet"
      sampled_requests_enabled   = true
    }
  }

  rule {
    name     = "AWS-AWSManagedRulesAnonymousIpList"
    priority = 2

    override_action {
      count {}
    }

    statement {

      managed_rule_group_statement {
        name        = "AWSManagedRulesAnonymousIpList"
        vendor_name = "AWS"

        excluded_rule {
          name = "AnonymousIPList"
        }
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "AWS-AWSManagedRulesAnonymousIpList"
      sampled_requests_enabled   = true
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "webacl-example"
    sampled_requests_enabled   = true
  }
}

Expected Behavior


I expected the resource aws_waf2_web_acl to just be updated and not recreated when I changed the priority of a rule for example.

Actual Behavior


When making any changes to the rules, the resource aws_wafv2_web_acl is recreated.

Steps to Reproduce

Just change the rule priority

bug servicwafv2

Most helpful comment

hi @phplucas, thank you for reporting this issue! I was able to reproduce this scenario, where just the priority attribute is changed w/in the rules after initial creation. As a user, I wouldn't expect to have to force replacement for this type of update. Further investigation is needed to see how we can workaround the diff being created and properly update in-place if indeed feasible. I'll update here accordingly.

All 9 comments

@phplucas Thanks for raising this issue.
Did the name of any of the rules change?
A WAFv2 rule's name cannot be changed after it has been created, so a change to a rule's name attribute forces the resource to be recreated.

The ACL is also recreated even if you just add new rules to it, without any reordering of priorities or any renaming:

      + rule { # forces replacement

The rule name has not been changed at any time. Any other configuration of the changed rule is a reason to recreate the web ACL, for example, the priority, the visibility config.

Is this really expected behavior?

As a complement, I did this same test with the resource aws_waf_web_acl (version 1) and the behavior is different, the web acl is just updated.

hi @phplucas, thank you for reporting this issue! I was able to reproduce this scenario, where just the priority attribute is changed w/in the rules after initial creation. As a user, I wouldn't expect to have to force replacement for this type of update. Further investigation is needed to see how we can workaround the diff being created and properly update in-place if indeed feasible. I'll update here accordingly.

Here are some examples I have encountered where the entire WAF is destroyed and recreated instead of being modified.
1) A managed rule toggles visibility_config.cloudwatch_metrics_enabled between true and false. This is possible in the console.
2) A managed rule is added (not altering the priorities of existing rules). This is possible in the console.
3) A non-managed rule adds or modifies a statement. This is possible in the console.
4) An excluded_rule statement is added or removed. This is possible in the console.

An "easy" fix might be to break out the rules as separate resources rather than having them all inline, that way the destructiuon and recreation could at least be confined to the rule itself instead of the entire WAF. Since these changes are all possible through the console in a non-destructive way, it must be possible through the API as well.

A fix has been merged and will release with v3.2.0 of the Terraform AWS Provider, expected out later today.

This has been released in version 3.2.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

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. Thanks!

Was this page helpful?
0 / 5 - 0 ratings