Support configurable max nested level for wafv2 rule statement

[MAXxATTAXx]

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

Allow during provider definition on terraform code to set the max level of nested statement supported by the schema.
Currently that value is hard coded to 3 max levels which excludes more complex use cases of the statement definition.

New or Affected Resource(s)

• aws_wafv2_rule_group
• aws_wafv2_web_acl

Potential Terraform Configuration

### Core rules
resource "aws_wafv2_rule_group" "core" {
  name        = "core"
  description = "Contains rules that are applicable for most web applications. (OWASP and more)"
  capacity    = 200
  scope       = "REGIONAL"

  ## SQLI

  ## XSS
  # body
  rule {
    name     = "xss_body"
    priority = 20

    action {
      block {}
    }

    statement {
      and_statement {
        # XSS inspection
        statement {
          xss_match_statement {
            field_to_match {
              body {}
            }

            text_transformation {
              priority = 0
              type     = "HTML_ENTITY_DECODE"
            }

            text_transformation {
              priority = 1
              type     = "URL_DECODE"
            }
          }
        }

        # Whitelist
         statement {
           not_statement {
             statement {
               and_statement {
                 statement {
                   byte_match_statement {
                     positional_constraint = "CONTAINS"
                     search_string         = "API-DOMAIN1"

                     field_to_match {
                       single_header {
                         name = "host"
                       }
                     }

                     text_transformation {
                       priority = 0
                       type     = "LOWERCASE"
                     }
                   }
                 }

                 statement {
                   byte_match_statement {
                     positional_constraint = "CONTAINS"
                     search_string         = "API-DOMAIN2"

                     field_to_match {
                       single_header {
                         name = "host"
                       }
                     }

                     text_transformation {
                       priority = 0
                       type     = "LOWERCASE"
                     }
                   }
                 }
               }
             }
           }
         }
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "xss_body"
      sampled_requests_enabled   = true
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "core"
    sampled_requests_enabled   = true
  }
}

References

[anGie44]

Hi @MAXxATTAXx, thank you for creating this issue! while the AWS Go SDK / APIs do allow for more than 3 levels of nesting, unfortunately within the provider, we've come across #14062 in the web_acl resource by supporting essentially 1 root statement and 3 nested statements which creates a challenging practitioner experience. so at this time, development to support this feature is blocked but I'll update here if there are any changes that can enable this request in the near future.

[demolitionmode]

Hi @anGie44, #14062 seems to be resolved now, is there anything else that is blocking development on this?

[ls-valentinas-bakaitis]

Hi @anGie44, just following up with a bit more details about this:

I hit the 3 level statement nesting limitation while creating a rule group and tried to work around it by using lifecycle and adding rule to ignore_changes, however even that does not work, terraform produces this error when running terraform plan after adding more than 3 levels of nested statements via AWS console:

Error: Error setting rule: Invalid address to set: []string{"rule", "0", "statement", "0", "and_statement", "0", "statement", "1", "not_statement", "0", "statement", "0", "and_statement"}

At this point I'm planning to completely remove the offending rule group from terraform and manage it manually, but would love to hear about any workarounds or developments in this area.

[stewartcampbell]

With each extra rule costing $1, this lack of ability is starting to get expensive for us. Anything slightly complex can't be completed in a single rule. We would be perfectly happy for a deployment to take more time if it saved us having to split up everything into multiple smaller rules.

[piotr-jagiello]

It's really not that hard to hit the limit of 3 nested statements, and it's incredibly upsetting that the limit is there, you essentially cripple a powerful AWS feature. I don't know what the provider does that even just 7 nested rules is slow, but unless it's literal hours I don't think it's worth removing the functionality altogether. Even 4 or 5 would be nice to have.

[olahouze]

Hello

Do you have any news about this case ?
It's vert penalizing...

[olahouze]

Hello, news from this issue ?

[breathingdust]

A workaround for this was added in v5.61.0 that allows you to specify the raw json in order to use a larger nested rule. The upstream Terraform issue still persists, and does result in the resource being virtually unusable with rules with any more than 3 levels of nesting (literal hours). My understanding is that the upstream issue is not likely to be resolved in the short term. We will keep this open in case the upstream issue does get fixed.

[kcul]

Hello, any progress for this issue, or any plan on this. raw_json is not a practical workaround, since no drift for it, the terraform loss its meaning!

[staizen-stephen]

Just hit this and agree that this needs a solution. It's already a pretty difficult resource API. Hitting additional limitations is unfortunate 😞