[Feature]: add hcloud_firewall_rule resource

[c33s]

What whould you like to see?

adding firewall rules to an existing firewall would be really awesome. it would help splitting respnsibilities. we create firewalls with terragrunt where the rules are read from a yaml file. the terragrunt config resides in a firewall subfolder. if i create a new server i would need to export all server_ips and roles as output and depend on it in the firewall module and add some logic to add the server ips based on their roles to the firewall. i would love to see the i can go the other way round and create a simple firewall and then in the server module i simply add the a new rule to a given firewall.

resource "hcloud_firewall" "myfirewall" {
  name = "my-firewall"
}

resource "hcloud_firewall_rule" "ping" {
  firewall_id = hcloud_firewall.myfirewall.id
  direction = "in"
  protocol  = "icmp"
  source_ips = [
      hcloud_server.example.ip4_address
      "0.0.0.0/0",
      "::/0"
  ]
}

[jooola]

Hey, could you tell us why you cannot do what you explained with the current provider? I currently don't see where the blocker is?

[c33s]

thank you for your fast response! while it is true that the current hcloud provider allows for adding rules during firewall creation, the feature i am requesting would help streamline our workflow and enhance flexibility when dealing with large-scale infrastructure.

1. separation of concerns: we split our terraform code into modular components using terragrunt, where different teams or modules are responsible for different parts of the infrastructure. right now, the firewall module has to gather all server ips (based on their roles and services) and manage firewall rules in one go. this centralizes too much logic in the firewall module, making it harder to manage as the environment scales. adding firewall rules directly within the server module would allow us to separate responsibilities clearly—firewalls handle overall access policies, while servers manage rules specific to their needs.

2. modular resource management: in general, it’s easier and cleaner to define resource creation in one location/module and allow other modules to add or connect items to that resource as needed. this pattern is already consistent with other hcloud resources:

• hcloud_firewall -> hcloud_firewall_attachment
• hcloud_network -> hcloud_server_network, hcloud_network_subnet
• hcloud_volume -> hcloud_volume_attachment
• hcloud_load_balancer -> hcloud_load_balancer_target
• hcloud_floating_ip -> hcloud_floating_ip_assignment

applying this same logic to firewall rules would be a natural fit. by introducing a hcloud_firewall_rule resource that could be added independently, we would maintain consistency across the provider and keep the code cleaner. it follows the same principle as adding firewalls to servers using hcloud_firewall_attachment, which allows us to manage resources flexibly and modularly.

3. avoiding data dependencies: in the current setup, the firewall module has to depend on outputs from the server module (like server ips and roles). this adds complexity because we must export these outputs, manage dependencies, and ensure that the firewall is applied correctly after any server changes. if we could add rules to an existing firewall from within the server module, it would reduce this need for tightly coupled dependencies and improve maintainability.

4. better scalability and flexibility: with the current approach, updating firewall rules means touching a shared resource, which could impact multiple services. if rules could be added per server, it reduces the risk of unintended consequences when modifying firewall rules for specific services. this also allows teams to iterate on firewall rules for their services independently.

to summarize, while the current provider can handle firewalls well in a monolithic setup, this feature would help improve modularity, separation of responsibilities, and scalability in environments using tools like terragrunt. it would allow us to manage infrastructure in a more decentralized, maintainable way while keeping consistent with other hcloud resources.

[jooola]

Have you considered adding multiple firewalls to your servers? Reading your use case, I understand that you try to pack everything in a single firewall, which indeed, might not scale well, is that correct?

[c33s]

we don't pack everything in one firewall but we want to keep the firewall count as low as possible to have good oversight over the security. we tried to use more firewalls but ended up having firewalls which are basically rules. of course it works but it is still "wrong"(tm). rules are something dynamic (we come from useing shorewall with ipsets), with the current interface of the cloud firewall they are quite static.

if the api and the provider have a rule interface it would even be possible to create an interface for fail2ban. with the current interface it is only possible to:

• create a new firewall
• with the new rule
• and assign it to the server

instead of

• adding a rule to an existing firewall which is already attached

[jfoliveira]

we don't pack everything in one firewall but we want to keep the firewall count as low as possible to have good oversight over the security. we tried to use more firewalls but ended up having firewalls which are basically rules. of course it works but it is still "wrong"(tm). rules are something dynamic (we come from useing shorewall with ipsets), with the current interface of the cloud firewall they are quite static.

I have the same perception. Having firewall rule as a separate resource would bring extra flexibility.

As a reference, without the intention of comparing Hetzner with other CSP, but just to have an alternative implementation as a reference, I would mention AWS terraform provider:

1. It used to manage firewall rules as "inline rules" as part of an AWS security group.
2. Over time that proved not be the best approach for flexibility, dynamically update just a single rule without updating the whole firewall, ...,
3. AWS terraform provider now clearly explains that with some warnings displayed in the AWS Security Group resource on [1].

[1] https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group

[jooola]

Thanks for both your inputs! I agree that some improvement can be made.

Our focus is currently on other topics, so I'll leave this open until we find some time to pick it up.