hashicorp / terraform-provider-aws

The AWS Provider enables Terraform to manage AWS resources.
https://registry.terraform.io/providers/hashicorp/aws
Mozilla Public License 2.0
9.81k stars 9.16k forks source link

WAF: Adding to WAF condition sets doesn't reflect in planning #462

Closed hashibot closed 4 years ago

hashibot commented 7 years ago

This issue was originally opened by @srikiraju as hashicorp/terraform#11102. It was migrated here as part of the provider split. The original body of the issue is below.


Terraform Version

Terraform v0.8.2

Affected Resource(s)

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

resource "aws_waf_sql_injection_match_set" "sqlcond" {
  name = "condname"
  sql_injection_match_tuples {
    text_transformation = "NONE"
    field_to_match {
      type = "QUERY_STRING"
    }
  }

  sql_injection_match_tuples {
    text_transformation = "URL_DECODE"
    field_to_match {
      type = "QUERY_STRING"
    }
  }
}

Expected Behavior

Changes made to match set manually should be visible in planning

Actual Behavior

Not visible. See steps section

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform apply
  2. Manually add additional match tuples to the match set.
  3. terraform plan - Doesn't revert or detect that changes were made

Important Factoids

I think this happens to a lot of stuff in WAF resources

alucena commented 7 years ago

Hello,

I'm experiencing a similarly behavior with version 0.9.8 also with aws_waf_web_acl resource. It seems any change made manually over the resources previously created by terraform doesn't update tfstate, so doing a terraform plan doesn't detect any change.

Terraform Configuration Files

resource "aws_waf_ipset" "IPblacklist_web_pool" {
  name = "IPblacklist"

  ip_set_descriptors = [
    {
      type  = "IPV4"
      value = "10.10.10.10/32"
    },
    {
      type  = "IPV4"
      value = "10.10.10.11/32"
    },
  ]
}
resource "aws_waf_rule" "block_IP_rule_web_pool" {
  name        = "BlockIPRuleWebPool"
  metric_name = "BlockIPRuleWebPool"

  predicates {
    data_id = "${aws_waf_ipset.IPblacklist_web_pool.id}"
    negated = false
    type    = "IPMatch"
  }
}
resource "aws_waf_web_acl" "ACL_web_pool" {
  name        = "WebPoolACL"
  metric_name = "WebPoolACL"

  default_action {
    type = "ALLOW"
  }

  rules 
    {
      action {
        type = "BLOCK"
      }
      priority = 1
      rule_id  = "${aws_waf_rule.block_IP_rule_web_pool.id}"
    }
}

Expected Behavior

Changes made manually should be visible in planning.

Actual Behavior

terraform plan doesn't show any change.

Steps to Reproduce

  1. terraform apply of the code above
  2. Manually change web ACL to COUNT (for example) in the Action of the rule instead of BLOCK
  3. terraform plan - Doesn't revert or detect that changes were made
davidcrx commented 7 years ago

+1

bflad commented 4 years ago

The fix for the original issue with aws_waf_sql_injection_match_set resource has been submitted: #11498

The separate issue in the above comment about the aws_waf_web_acl resource should have been addressed roughly a year and a half ago in version 1.30.0 of the Terraform AWS Provider.

bflad commented 4 years ago

The fix for the aws_waf_sql_injection_match_set resource has been merged and will release with version 2.46.0 of the Terraform AWS Provider, Thursday next week.

ghost commented 4 years ago

This has been released in version 2.46.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!

ghost commented 4 years ago

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!