Open borisceranic opened 1 month ago
Hey @borisceranic,
looks like this bug was introduced in #874, first released in 1.46.0. This only happens if you omit the /32
at the end of your allowed IPs. If you specify them, no rules are being removed:
resource "hcloud_firewall" "test" {
name = "firewall_1"
apply_to {
label_selector = "test/label-1"
}
rule {
description = "allow all traffic from particular IPs"
direction = "in"
protocol = "tcp"
port = "1-65535"
source_ips = [
"1.2.3.4/32",
"1.3.4.5/32",
]
}
}
We will take a look at this.
This is reproducable with this e2e test:
func TestFirewallResource_Regression931(t *testing.T) {
var f hcloud.Firewall
res := firewall.NewRData(t, "update-keep-rules", []firewall.RDataRule{
{
Direction: "in",
Protocol: "tcp",
SourceIPs: []string{"192.0.2.250"},
Port: "80",
Description: "allow http in",
},
}, nil)
updated := &firewall.RData{
Name: "update-keep-rules-changed",
Rules: res.Rules,
ApplyTo: res.ApplyTo,
Labels: res.Labels,
}
updated.SetRName(res.RName())
tmplMan := testtemplate.Manager{}
resource.Test(t, resource.TestCase{
PreCheck: teste2e.PreCheck(t),
ProtoV6ProviderFactories: teste2e.ProtoV6ProviderFactories(),
CheckDestroy: testsupport.CheckResourcesDestroyed(firewall.ResourceType, firewall.ByID(t, &f)),
Steps: []resource.TestStep{
{
Config: tmplMan.Render(t, "testdata/r/hcloud_firewall", res),
Check: testsupport.CheckResourceExists(res.TFID(), firewall.ByID(t, &f)),
},
{
// Update something other than the rules
Config: tmplMan.Render(t, "testdata/r/hcloud_firewall", updated),
},
},
})
}
Hey @apricote ,
looks like this bug was introduced in #874, first released in 1.46.0. This only happens if you omit the
/32
at the end of your allowed IPs. If you specify them, no rules are being removed:
Thanks, that's a viable workaround, I'll implement it as a stop-gap solution to prevent possible issues, until the provider is fixed.
By the way: are you saying that if I stick with the provider 1.45.0 or older (for the time being) that the issue would not happen?
By the way: are you saying that if I stick with the provider 1.45.0 or older (for the time being) that the issue would not happen?
In theory yes, but before 1.46.0 you got an error if you specified the IP directly without /32
, so you would still have to add that to your configuration.
Looks like we are running into the same bug as described here: https://github.com/hetznercloud/terraform-provider-hcloud/pull/468
What happened?
While working with
hcloud_firewall
resource, I noticed that ALL RULES are silently deleted by Terraformhcloud
provider when Terraform wants to update the firewall in-place in cases when any argument (other thanrule
) changes.Consider this example:
Terraform creates the resource, and it appears Just Fine (tm) in the Hetzner Cloud Console:
Then, if I update only
name
argument, Terraform plan shows something that appears perfectly normal and expected:Similarly, here's a perfectly normal-looking plan output when changing
apply_to.label_selector
argument:Meanwhile, looking at the Cloud Console, the end result is actually a removal of ALL RULES:
The following re-run of
terraform plan
will first refresh all resources, it will pick up the missing rules, and then it will helpfully offer to re-create them on the nextapply
:What did you expect to happen?
When changing
name
,labels
andapply_to
arguments, I expected rules specified via therule {}
block to remain set in the firewall.Please provide a minimal working example