[Bug]: unable to find the wafv2acl aws resource that is shown to be created using terraform in the waf console

[Melvind1117]

Terraform Core Version

1.7.5

AWS Provider Version

5.43.0

Affected Resource(s)

aws_wafv2_web_acl

Expected Behavior

aws_wafv2_web_acl global cloudfront scope type aws waf resource must have got added on apply as per plan.

Actual Behavior

aws_wafv2_web_acl global cloudfront scope type aws waf resource did not reflect in console/is not added on apply as per plan.

Relevant Error/Panic Output Snippet

aws_wafv2_web_acl.prod_wafv2webacl: Creation complete after 3s

have created the wafv2acl resource in cloudfront scope using terraform IAC in our aws account and the terraform apply stage gives us with output ids of the aws waf resources created using terraform but still we are unable to find the wafv2acl aws resource that is shown to be created using terraform in the waf console in the us-east-1 region for the cloudfront scope.please help us resolve this as the wafv2acl aws resource is not available in aws waf console. Please find the attached terraform apply stage logs and the resource ids that were shown to be created in the terraform apply logs.frequently perform terraform operations using the same terraform release pipeline which uses the correct aws access credentials to provision other aws resources .But ,still deviating from the terraform-aws provider plan output the apply stage has failed to provision the aws waf related resources in the particular aws account.

Note: frequently provison other aws services resources and manage our entire aws account with terraform and the issues is faced only with the waf related aws resources only provided the aws access is correct.Kindly check if the terraform-aws provider functionality for wafv2acl resource provisoning has any reported persisting issues before-on in any scenarios.

Terraform Configuration Files

provider "aws" {
  alias  = "us_east_1"
  region = "us-east-1"
}

data "aws_caller_identity" "current" {}

data "aws_region" "current" {
 provider = aws.us_east_1
}

resource "aws_wafv2_web_acl" "atp-example" {
  name        = "managed-atp-example"
  description = "Example of a managed ATP rule."
  scope       = "CLOUDFRONT"
  provider = aws.us_east_1
  default_action {
    allow {}
  }

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

    override_action {
      count {}
    }

    statement {
      managed_rule_group_statement {
        name        = "AWSManagedRulesATPRuleSet"
        vendor_name = "AWS"

        managed_rule_group_configs {
          aws_managed_rules_atp_rule_set {
            login_path = "/api/1/signin"

            request_inspection {
              password_field {
                identifier = "/password"
              }

              payload_type = "JSON"

              username_field {
                identifier = "/email"
              }
            }

            response_inspection {
              status_code {
                failure_codes = ["403"]
                success_codes = ["200"]
              }
            }
          }
        }
      }
    }

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

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

Steps to Reproduce

provider "aws" {
  alias  = "us_east_1"
  region = "us-east-1"
}

data "aws_caller_identity" "current" {}

data "aws_region" "current" {
 provider = aws.us_east_1
}

resource "aws_wafv2_web_acl" "atp-example" {
  name        = "managed-atp-example"
  description = "Example of a managed ATP rule."
  scope       = "CLOUDFRONT"
  provider = aws.us_east_1
  default_action {
    allow {}
  }

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

    override_action {
      count {}
    }

    statement {
      managed_rule_group_statement {
        name        = "AWSManagedRulesATPRuleSet"
        vendor_name = "AWS"

        managed_rule_group_configs {
          aws_managed_rules_atp_rule_set {
            login_path = "/api/1/signin"

            request_inspection {
              password_field {
                identifier = "/password"
              }

              payload_type = "JSON"

              username_field {
                identifier = "/email"
              }
            }

            response_inspection {
              status_code {
                failure_codes = ["403"]
                success_codes = ["200"]
              }
            }
          }
        }
      }
    }

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

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

Debug Output

No response

Panic Output

No response

Important Factoids

No response

References

No response

Would you like to implement a fix?

None

[github-actions[bot]]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• 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.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[justinretzolk]

Hey @Melvind1117 👋 Thank you for taking the time to raise this! Are you able to supply debug logs (redacted as needed)? I suspect this isn't a bug with the provider, but it may be worth using the aws CLI's get-web-acl command to get information about the web ACL and confirm its creation.

[Melvind1117]

Hey @Melvind1117 👋 Thank you for taking the time to raise this! Are you able to supply debug logs (redacted as needed)? I suspect this isn't a bug with the provider, but it may be worth using the aws CLI's get-web-acl command to get information about the web ACL and confirm its creation. The aws cli get web acl command will not return any response as the aws waf resource ids that were shown to be created in apply logs are not present when we check from the aws console . please find the attached logs herewith: module.security.aws_wafv2_ip_set.wafv2ipset2: Creation complete after 0s [id=XXX] module.security.aws_wafv2_ip_set.wafv2ipset3: Creation complete after 0s [id=XXXX] module.security.aws_wafv2_ip_set.wafv2ipset: Creation complete after 0s [id=XXXX] module.security.aws_wafv2_web_acl.wafv2webacl: Creating... module.security.aws_wafv2_web_acl.wafv2webacl: Creation complete after 3s [id=XXXX]

[Melvind1117]

Hey @Melvind1117 👋 Thank you for taking the time to raise this! Are you able to supply debug logs (redacted as needed)? I suspect this isn't a bug with the provider, but it may be worth using the aws CLI's get-web-acl command to get information about the web ACL and confirm its creation. The aws cli get web acl command will not return any response as the aws waf resource ids that were shown to be created in apply logs are not present when we check from the aws console . please find the attached logs herewith: module.security.aws_wafv2_ip_set.wafv2ipset2: Creation complete after 0s [id=XXX]�[0m module.security.aws_wafv2_ip_set.wafv2ipset3: Creation complete after 0s [id=XXXX]�[0m module.security.aws_wafv2_ip_set.wafv2ipset: Creation complete after 0s [id=XXXX]�[0m module.security.aws_wafv2_web_acl.wafv2webacl: Creating...�[0m�[0m module.security.aws_wafv2_web_acl.wafv2webacl: Creation complete after 3s [id=XXXX]�[0m

The ipsets that were shown to be created by the logs also belong to the cloudfront scope and were assigned resource ids by the aws api call successfully but the cloudfront scope ipsets are also not visible in the aws console

[acwwat]

It might be a silly thing to point out, but the way web ACLs are displayed in the AWS Management Console can be tricky. The service itself becomes global and you have to use a drop-down to select the region. For me, us-east-1 is selected when I open the page, so I'd have to change it to "Global (CloudFront)" to see the globally-scoped web ACLs. It doesn't hurt to double check in the UI, since Terraform says the resource is created by the AWS Management Console doesn't seem to.

[Melvind1117]

It might be a silly thing to point out, but the way web ACLs are displayed in the AWS Management Console can be tricky. The service itself becomes global and you have to use a drop-down to select the region. For me, us-east-1 is selected when I open the page, so I'd have to change it to "Global (CloudFront)" to see the globally-scoped web ACLs. It doesn't hurt to double check in the UI, since Terraform says the resource is created by the AWS Management Console doesn't seem to.

Have checked under the highlighted section already ,but seems the cloudfront scope ipsets and wafv2acl aws resource IDs that were returned as response from terraform apply stage as created are not visible within those either.

[acwwat]

Hmmm then the only other thing I would suggest is to open the Terraform state file and find the arn attribute of the aws_wafv2_web_acl resource just to double check the account ID in the ARN is the same as what you see in the upper right hand corner of the AWS Management Console. This hopefully confirms or eliminates the possibility that the credentials/profile used by Terraform is tied to the same account that you are accessing with the AWS Management Console.

Otherwise we'd need Terraform debug logs, the output of your AWS API calls, and maybe screenshots of your AWS Management Console to continue troubleshooting.

[Melvind1117]

Hi, if possible, please help by doing a dry-run with the below attached terraform file that was used exactly in the highlighted cloudfront scope waf creation issue scenario: main.txt

[acwwat]

Hi, if possible, please help by doing a dry-run with the below attached terraform file that was used exactly in the highlighted cloudfront scope waf creation issue scenario: main.txt

Aside from a space at the beginning of description, the Terraform configuration applies successfully and I can see the web ACL cloudfront_wafv2webacl in AWS Management Console with "Global (CloudFront)" selected as expected.

Thus I think you should follow through with double checking the account ID and providing debugging info.

[Melvind1117]

Hi, if possible, please help by doing a dry-run with the below attached terraform file that was used exactly in the highlighted cloudfront scope waf creation issue scenario: main.txt

Aside from a space at the beginning of description, the Terraform configuration applies successfully and I can see the web ACL cloudfront_wafv2webacl in AWS Management Console with "Global (CloudFront)" selected as expected.

Thus I think you should follow through with double checking the account ID and providing debugging info.

Hi ,the scenario to note is that majority of our aws resources are provisoned in the one region and only for this global waf resource we have implemented the us-east-1 region with the alias as highlighted in the code attached and analyzing if the us-east-1 region implementation as alias could have caused the global waf creation request not to reach the aws backend.

[justinretzolk]

Hey @Melvind1117 👋 Given that Anthony was able to use the reproduction configuration without issue, it would appear that this isn't a bug with the provider. We use issues in this repository to track bugs and feature requests in the AWS provider, so you're unlikely to get the kind of responsiveness that would be helpful here. With those things in mind, I'm going to close this issue. It might be worthwhile to ask in the AWS provider forums if you'd like additional assistance from the community.

[github-actions[bot]]

[!WARNING] This issue has been closed, meaning that any additional comments are hard for our team to see. Please assume that the maintainers will not see them.

Ongoing conversations amongst community members are welcome, however, the issue will be locked after 30 days. Moving conversations to another venue, such as the AWS Provider forum, is recommended. If you have additional concerns, please open a new issue, referencing this one where needed.

[github-actions[bot]]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.