Closed AlexandreGohier closed 1 year ago
Voting for Prioritization
Volunteering to Work on This Issue
Having the same issue here, right after start using the rule_action_override
block.
This is the change that introduced this new feature, is it worth reverting? https://github.com/hashicorp/terraform-provider-aws/pull/27954
Same issue terraform v1.1.7 aws v4.45.0
count seems to fail but allow works.
rule_action_override { action_to_use { count {} } name = "NoUserAgent_HEADER" }
rule_action_override { action_to_use { allow {} } name = "NoUserAgent_HEADER" }
originally used exclude_rule
same issue in our environment - reverting to the depreciated block allowed us to update the ACL successfully.
that issue has been resolved? I am having the same issue as well.
Blocks of type "rule_action_override" are not expected here.
I am also facing similar issue https://github.com/hashicorp/terraform-provider-aws/issues/28672
As a workaround I have been tainting my web acl when rules are impacting changes to webacl.
I keep the same webacl name so that my WAF logs do not get impacted.
Edit: See next comment below for a workaround that works for me
@ewbankkit I think I found something leading to part of the root cause here based on some investigation I did on the plan json that can reproduce the issue and a "workaround". Will dig more when I get a chance but this seems to be a workaround in my case.
This schema here is an optional list: https://github.com/hashicorp/terraform-provider-aws/blob/f7cf1351f83ed0124725a65382a00b91931ff1c0/internal/service/wafv2/schemas.go#L591
When I add or modify any aws_wafv2_web_acl.rule
attribute or add a new aws_wafv2_web_acl.rule
it creates the following discrepancy for all rules for aws_wafv2_web_acl.rule.statement.managed_rule_group_statement.rule_action_override.action_to_user.*.custom_request_handling
In my plan file's json the resource_changes
section shows this...
# Before section...
"action_to_use": [
{
"allow": [],
"block": [],
"captcha": [],
"count": [
{
"custom_request_handling": null
}
]
}
]
# After section...
"action_to_use": [
{
"allow": [],
"block": [],
"captcha": [],
"count": [
{
"custom_request_handling": []
}
]
}
]
If I ensure there is something populated in custom_request_handling
then this error is fixed for my use case.
# BEFORE AND CAUSING ISSUES
dynamic "rule_action_override" {
for_each = managed_rule_group_statement.value.count_rule_action_overrides
content {
action_to_use {
count {
}
}
name = rule_action_override.key
}
}
# AFTER
dynamic "rule_action_override" {
for_each = managed_rule_group_statement.value.count_rule_action_overrides
content {
action_to_use {
count {
custom_request_handling {
insert_header {
name = "TFWorkaround"
value = "WAF"
}
}
}
}
name = rule_action_override.key
}
}
Once I make these changes the before and after plans still show changes to all the rules but don't crash on apply.
Thank you @bclodius for the work around!! I can confirm that changing action_to_use.count
to include the custom_requrest_handling.insert-header
block was able to get me past the issue on AWS v4.53.0. Seems like a fairly high severity bug since it prevents a successful terraform apply. I hope it gets fixed soon.
This bug is not limited to the waf2 resource. I got the error on routing tables:
When expanding the plan for module.network.aws_route_table.<table>[1] to include new values learned so
far during apply, provider "registry.terraform.io/hashicorp/aws" produced an invalid new value for .route: planned set
element cty.ObjectVal(map[string]cty.Value{"carrier_gateway_id":cty.NullVal(cty.String),
"cidr_block":cty.StringVal("0.0.0.0/0"), "core_network_arn":cty.NullVal(cty.String),
"destination_prefix_list_id":cty.NullVal(cty.String), "egress_only_gateway_id":cty.NullVal(cty.String),
"gateway_id":cty.NullVal(cty.String), "instance_id":cty.NullVal(cty.String), "ipv6_cidr_block":cty.NullVal(cty.String),
"local_gateway_id":cty.NullVal(cty.String), "nat_gateway_id":cty.StringVal("nat-abcd12345"),
"network_interface_id":cty.NullVal(cty.String), "transit_gateway_id":cty.NullVal(cty.String),
"vpc_endpoint_id":cty.NullVal(cty.String), "vpc_peering_connection_id":cty.NullVal(cty.String)}) does not correlate with
any element in actual.
I hope this gets fixed soon, because this breaks all new applies...
@bclodius the workaround which you mentioned what exactly does it do? Just wondering if there's some impact i need to careful about
@amitsamal94 the workaround just ensures that the plan doesn't end up in a situation that causes the error. The bug gets triggered when there's NOTHING overridden in the override. In my case I had to force an extra header in the rule override config. This extra header doesn't impact my application.
@bclodius , thanks
I can confirm this bug is present on v4.52.0
also.
Please fix this with high priority. I currently breaks central WAF rule changes.
Workaround helps to ease the pain. Thx so far!
v4.59.0 is also affected.
Also see this error. Do we know when a fix will be in place?
Also present in v4.60.0.
any update on same, its present in v4.60.0
This observed me for below resource
"registry.terraform.io/hashicorp/null" produced an invalid new value for │ .triggers["image_name_trigger"]: was │ cty.StringVal("***.dkr.ecr.ap-northeast-1.amazonaws.com/akt-frontend-uploader:2c056e3322f0286ae1117627cc8f688eded5e2f539bd08e375b293a9634b5161"
Hey all, I have come across a similar issue this week too. I'm aiming to look deeper into the issue and implement a fix hopefully. If anyone is interested in pairing with me on this issue, that would be great!
Update:
I have done some digging and it could be any of these 2 issues which have stood out. The first issue could be with the way the custom request handling is handled during the creation and update of web ACLs.
1) In the func resourceWebACLCreate
in web_acl.go
that is here - it seems that we need to handle this (custom_request_handling) in the webACL.
2) Another potential issue is that the schema mentioned by @bclodius in his workaround; yes, the customRequestHandlingSchema
is optional, however, the insert_header
schema is set to required and perhaps it could also be this. The children of insert_header
(name
& value
) are also set to required. Perhaps making the insert_header
to optional could be a fix ?
If Go experts could take a look at this and perhaps comment or suggest something, it would be awesome!
Is there any update on this? Confirming bug on resource tag
update operations, at the very least. Terraform core version: 1.2.3
, AWS provider version: v4.19.0
. Thank you!
Having the same issue, Terraform 1.3.3 and AWS provider 4.63.0
Facing the same issue in terraform ~> 1.3.0 and AWS provider 4.63.0
I am experiencing the same issue, but not with the action_to_use
override construct, but with a regular allow
or count
within a dynamic rule
creation.
Using the same method described above, the workaround is successful here too.
dynamic "rule" {
for_each = var.custom_rules
content {
name = rule.key
priority = try(rule.value["priority"], "100")
# What rule action do we want to apply
action {
dynamic "allow" {
for_each = rule.value["action"] == "allow" ? [true] : []
content {
# --------------------------------------------------------------------
# Adding a custom header as a workaround for a BUG in the AWS provider
# See https://github.com/hashicorp/terraform-provider-aws/issues/28191
# --------------------------------------------------------------------
custom_request_handling {
insert_header {
name = "TFWorkaround"
value = "WAF"
}
}
}
}
:
:
:
V5.0.1 removes excluded_rules
, so rule_action_override
is the only alternative. Was this fixed in 5.0.1 or is it still broken?
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).
@YakDriver thanks for the update. Do you have any suggestions on the minimum aws provider version to try this on?
With Terraform v1.5.3 and AWS provider v5.8.0, I am no longer experiencing this error! Thanks @YakDriver
@YakDriver thanks for the update. Do you have any suggestions on the minimum aws provider version to try this on?
@bclodius It depends on the exact subpart of this family of issues. If yours is similar to the op on this issue, I suggest trying a minimum of Terraform v1.4.2 and AWS provider v4.67.0.
With Terraform v1.5.3 and AWS provider v5.8.0, I am no longer experiencing this error! Thanks @YakDriver
Thanks @AlexandreGohier for reporting back!
Hi all :wave: 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. 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.
Related:
23390
23423
23936
23992
24386
27175
27273
27479
28672
29012
29304
30858
Terraform Core Version
1.3.5
AWS Provider Version
4.45.0
Affected Resource(s)
Expected Behavior
We should now use
rule_action_override
instead of deprecated
excluded_rule
Actual Behavior
When using
dynamic rule_action_override
block, the webacl gets created or updated as expected. However, subsequent updates are impossible :Error: Provider produced inconsistent final plan
Reverting to
excluded_rule
allows new updates to the webacl.Relevant Error/Panic Output Snippet
Terraform Configuration Files
Steps to Reproduce
1- Create or update webacl to use
rule_action_override
(and apply) 2- Modify something in the code that will require a webacl update (and apply) --> this will produce an inconsistant final plan 3- Revert toexcluded_rule
(and apply) --> works fine and further webacl updates are possibleDebug Output
No response
Panic Output
No response
Important Factoids
Tested on Ubuntu 22.04
References
No response
Would you like to implement a fix?
None