Support for X-Forwarded-For header in aws_wafv2_web_acl rate_based_statement

[mkubenka]

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

Description

AWS WAF now supports inspecting the X-Forwarded-For (XFF), True-Client-IP, or other custom header that includes the originating IP address of a client connecting to your application through an HTTP proxy or a third-party CDN. With this feature, you can reference these headers to write rate-based rules, geographic match rules, or IP match rules, allowing you to take action on IPs that are found within these headers. Both IPv4 and IPv6 addresses are supported.

New or Affected Resource(s)

• aws_wafv2_web_acl

Potential Terraform Configuration

resource "aws_wafv2_web_acl" "example" {
  name        = "rate-based-example"
  description = "Example of a rate based statement."
  scope       = "REGIONAL"

  default_action {
    block {}
  }

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

    action {
      count {}
    }

    statement {
      rate_based_statement {
        limit              = 10000
        aggregate_key_type = "FORWARDED_IP"

        forwarded_ip_config {
          header_name = "X-Forwarded-For"
          fallback_behavior = "MATCH"
        }

        scope_down_statement {
          geo_match_statement {
            country_codes = ["US", "NL"]
          }
        }
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = false
      metric_name                = "friendly-rule-metric-name"
      sampled_requests_enabled   = false
    }
  }

  tags = {
    Tag1 = "Value1"
    Tag2 = "Value2"
  }

  visibility_config {
    cloudwatch_metrics_enabled = false
    metric_name                = "friendly-metric-name"
    sampled_requests_enabled   = false
  }
}

References

• https://aws.amazon.com/about-aws/whats-new/2020/07/support-x-forwarded-for-header-available-aws-waf/

[anGie44]

Hi @mkubenka, thank you for submitting this issue! We'll first need to update our aws-sdk-go dependency to atleast v1.33.5 (aws/aws-sdk-go#3416) to support this forwarded_ip_config attribute w/in the rate_based_statement in addition to the new aggregate_key_type value as we're currently on v1.32.12. Luckily #14000 will include these API changes and will unblock development efforts to address this enhancement 😃

[cisnerosk]

@anGie44 thanks for looking at this request.. it's also a blocker for us in having a more robust WAFV2 w/ Terraform. Just for my clarification, will the update only support within the rate_base_statement/aggregate_key_type or will this also work for geo_match_statements & or_statements? I have a use case where I need to have a geo_match nested inside an or_based statement that relies on the X-Forwarded-For match. Please let me know if I should submit a new ticket or wait for updates on this one.

[anGie44]

Hi @cisnerosk, apologies for the delay! We can add the IPForwardedConfig to the geo match statement as well to align with the support now added in the AWS Go SDK. If you don't mind, could you create an issue for that specific statement type to keep track of it? It will affect both the webACL and rule group resources.

[cisnerosk]

Hello @anGie44 thank you so much for the response! I've created this issue here: #14725 I hope it helps, and I'll keep track of that one.

Thank you!

[anGie44]

This feature has been merged and will release with v3.3.0 of the Terraform AWS Provider, likely out later this evening (EST).

[ghost]

This has been released in version 3.3.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]

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!