-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aws_wafv2_web_acl - Error: Provider produced inconsistent final plan #23992
Comments
I also was removing tags, I had moved some to the default tags for the provider provider "aws" {
region = "us-east-1"
default_tags {
tags = {
stack = terraform.workspace
purpose = "example"
}
}
} I found that if I do only that, it fails with the error you mentioned. But if I also make some other arbitrary change to the web acl rules, such as changing a rule priority slightly, then it does not fail. |
I'm getting this exact error when I change the |
Running into this issue on multiple environments. Current workaround for me is to just not modify any tags, which is only a short-term solution. Ideally, it looks like this just needs fixed. |
this is happening to me on the latest 4.23.0 aws provider version. |
Same issue here. I have tried to update This may be related to #23423 and #24386 . I work around the error by using ref: #24386 (comment) |
Every time we apply, we update a timestamp tag which is in the provider defaults tags, if there are changes to the WAF rules, we can apply without issues, but if the only change is a tag being updated we get this panic. I noticed this after upgrading from this provider from v3 to v4, we haven't changed the use of |
Bumping this to keep the bots at bay. |
As a workaround, I've just changed priority of rules, so let terraform also modify rules with tags. |
Also impacted by this with
|
To add I am hitting this same error on almost every change. Using provider "hashicorp/aws v4.50.0" My workaround is to change the priority of all of the rules and then the change will apply which is awkward as the number of rules increases. Anecdotally i only started to see this issue after migrating from exclude to rule_action_override blocks for the managed rule group statement. |
when can this be fixed? |
Came here to post that changing one of the waf rule priorities manually, then running plan/apply succeeded for me as a workaround (AWS Provider v4.52.0). (Edit: AWS Provider 4.52.0) |
Yes the nature of the issue is if there are NO changes and you apply you get this error, if there are any changes that are required, there is no issue But making manual changes so that an automated process does not error isn't ideal |
Agreed - not ideal. In my case we have 19 similar environments with only two encountering this error. |
I also face this issue when I try to add more rule by using the dynamic block
|
I had the same issue. See this comment which worked for me. Hope it helps. Kudos to the author. |
Upgrading terraform to 1.4.x fixed this for me |
I upgraded to 1.4 last week, but my errors persist
…On Tue, 28 Mar 2023, 16:10 Antonio Pagliara, ***@***.***> wrote:
Upgrading terraform to 1.4.x fixed this for me
—
Reply to this email directly, view it on GitHub
<#23992 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB626UTPYXDWTUAXWVLF6ELW6LWL5ANCNFSM5SIAOXHQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Looks like I was wrong, the errors in the pipeline last week must have been from something else. I was able to apply the same resource with no changes without a stack trace being generated. But it looks like it's because it is applying changes to the waf each time, regardless of whether there are real changes. But regardless, the stack traces have stopped for now. |
NOTE: I cannot reproduce this error using Terraform v1.5+/AWS provider v5.7+ after trying various configurations. Retry using a minimum of Terraform v1.4.2/AWS provider v4.67.0 but preferably Terraform v1.5.3+/AWS provider v5.8.0+ and let us know if this is still a problem! If we don't hear back and can't reproduce, we plan to close this on or around July 20, 2023. The evidence suggests this is OBE (ie, fixed in the interim). For more details see #23992 (comment) and #28672 (comment). I had no problems (no errors or inconsistent final plans) with these configurations. I applied Config 1 (tags + default tags), then Config 2 (exact same except it removes tags, removes default tags), then Config 1 again. (Region must be Using:
Config 1provider "aws" {
default_tags {
tags = {
fine_night = "tonight"
fine_day = "tomorrow"
}
}
}
resource "aws_wafv2_ip_set" "test" {
name = "wafv23992test"
scope = "CLOUDFRONT"
ip_address_version = "IPV4"
addresses = ["1.2.3.4/32", "5.6.7.8/32"]
}
resource "aws_wafv2_web_acl" "test" {
name = "wafv23992test"
scope = "CLOUDFRONT"
default_action {
block {}
}
rule {
name = "Whitelist-WAF-ACLs-rule"
priority = 0
action {
allow {}
}
statement {
ip_set_reference_statement {
arn = aws_wafv2_ip_set.test.arn
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-rule"
sampled_requests_enabled = true
}
}
rule {
name = "AWSManagedRulesBotControlRuleSet"
priority = 1
override_action {
count {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesBotControlRuleSet"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-menaged-rule"
sampled_requests_enabled = true
}
}
rule {
name = "AWSManagedRulesAdminProtectionRuleSet"
priority = 2
override_action {
count {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesAdminProtectionRuleSet"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-menaged-rule"
sampled_requests_enabled = true
}
}
rule {
name = "AWSManagedRulesAmazonIpReputationList"
priority = 3
override_action {
count {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesAmazonIpReputationList"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-menaged-rule"
sampled_requests_enabled = true
}
}
rule {
name = "AWSManagedRulesAnonymousIpList"
priority = 4
override_action {
count {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesAnonymousIpList"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-menaged-rule"
sampled_requests_enabled = true
}
}
rule {
name = "AWSManagedRulesCommonRuleSet"
priority = 5
override_action {
count {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesCommonRuleSet"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-menaged-rule"
sampled_requests_enabled = true
}
}
rule {
name = "AWSManagedRulesKnownBadInputsRuleSet"
priority = 6
override_action {
count {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesKnownBadInputsRuleSet"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-menaged-rule"
sampled_requests_enabled = true
}
}
rule {
name = "AWSManagedRulesSQLiRuleSet"
priority = 7
override_action {
count {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesSQLiRuleSet"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-menaged-rule"
sampled_requests_enabled = true
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-metric"
sampled_requests_enabled = true
}
tags = {
Name = "wafv23992test"
Application = "wafv23992test"
Cost = "wafv23992test"
Environment = "wafv23992test"
Owner = "wafv23992test"
Project = "wafv23992test"
TeamName = "wafv23992test"
Entity = "wafv23992test"
}
depends_on = [aws_wafv2_ip_set.test]
} Config 2resource "aws_wafv2_ip_set" "test" {
name = "wafv23992test"
scope = "CLOUDFRONT"
ip_address_version = "IPV4"
addresses = ["1.2.3.4/32", "5.6.7.8/32"]
}
resource "aws_wafv2_web_acl" "test" {
name = "wafv23992test"
scope = "CLOUDFRONT"
default_action {
block {}
}
rule {
name = "Whitelist-WAF-ACLs-rule"
priority = 0
action {
allow {}
}
statement {
ip_set_reference_statement {
arn = aws_wafv2_ip_set.test.arn
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-rule"
sampled_requests_enabled = true
}
}
rule {
name = "AWSManagedRulesBotControlRuleSet"
priority = 1
override_action {
count {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesBotControlRuleSet"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-menaged-rule"
sampled_requests_enabled = true
}
}
rule {
name = "AWSManagedRulesAdminProtectionRuleSet"
priority = 2
override_action {
count {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesAdminProtectionRuleSet"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-menaged-rule"
sampled_requests_enabled = true
}
}
rule {
name = "AWSManagedRulesAmazonIpReputationList"
priority = 3
override_action {
count {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesAmazonIpReputationList"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-menaged-rule"
sampled_requests_enabled = true
}
}
rule {
name = "AWSManagedRulesAnonymousIpList"
priority = 4
override_action {
count {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesAnonymousIpList"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-menaged-rule"
sampled_requests_enabled = true
}
}
rule {
name = "AWSManagedRulesCommonRuleSet"
priority = 5
override_action {
count {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesCommonRuleSet"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-menaged-rule"
sampled_requests_enabled = true
}
}
rule {
name = "AWSManagedRulesKnownBadInputsRuleSet"
priority = 6
override_action {
count {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesKnownBadInputsRuleSet"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-menaged-rule"
sampled_requests_enabled = true
}
}
rule {
name = "AWSManagedRulesSQLiRuleSet"
priority = 7
override_action {
count {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesSQLiRuleSet"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-menaged-rule"
sampled_requests_enabled = true
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "Whitelist-WAF-ACLs-metric"
sampled_requests_enabled = true
}
depends_on = [aws_wafv2_ip_set.test]
} |
Using my sample code and how to reproduce is still occurring, see issue: #28672 I am also using using AWS provider v5.8.0 |
Hi all 👋 As was mentioned above, this issue appears to be fixed when using a minimum Terraform version of 1.4.2 and a minimum AWS Provider version of 4.67.0 (preferably Terraform 1.5.3 or later and AWS Provider 5.8.0 or later). If you experience additional unexpected behaviors with versions that meet these parameters, please open a new issue so that we can investigate further. |
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. |
Community Note
Related:
aws_wafv2_web_acl
#27175 (27)aws_wafv2_web_acl
configurations #27273 (42)aws_wafv2_web_acl
description/tag changes result in inconsistent final plan #27479 (20)Terraform CLI and Terraform AWS Provider Version
Terraform version 1.1.7
provider registry.terraform.io/hashicorp/aws v4.8.0
Affected Resource(s)
Terraform Configuration Files
Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.
Debug Output
Panic Output
Expected Behavior
I am trying to make a update to the config, this particular change is for removing tags
Actual Behavior
It does not deploy, it throws the error;
Steps to Reproduce
terraform apply
Important Factoids
References
The text was updated successfully, but these errors were encountered: