Closed christoph-buente closed 8 months ago
You are right, especially in the context of a Hetzner a managed Hetzner firewall would be the better idea, especially since the UFW will not cover accidental port exposure from docker containers. The next release will contain a "real" private option where the port is only bound to the local interface. I would like to keep the firewall option because it adds another layer of security bit it should be no issue to make it optional.
I deactivated ufw
in the post_script. I moved the ssh port from port 22
to 22022
. And then I locked myself out. Took me a while to figure out that there is not only the Hetzner firewall but also a local firewall going on. BTW, moving away from the standard SSH port removes 95% of connection attempts and brings a lot of security improvements.
And yes, binding the postgresql to a private network instead of the public address would be great. My setup is talking via the private network, which makes sure the traffic does not get routed to the public internet. No need to expose the DB unless needed.
as per https://github.com/pellepelster/solidblocks/commit/7d602de9e395ce15b037791756690d087368c08a if a network_ip
is provided the database will from now on automatically be bound to that ip.
also https://github.com/pellepelster/solidblocks/commit/47dfc94d229dab111916306814572f1cbe6e48b3 will allow to disable the firewall with firewall_disable
.
I am still undecided about the whole firewall thing, my feeling is that also managing the FW introduces a lot of complexity that is kind of out of scope of the DB module and to slowly phase out that feature
Awesome, this is great. Thank you!
both options are now available in v0.2.4
https://github.com/pellepelster/solidblocks/blob/5444af56915a988fe0d5c4f55c89323f2533ac62/solidblocks-hetzner/modules/rds-postgresql/user_data.sh#L201
Hey @pellepelster,
I was fiddling with the option to move SSH to a different port and always got locked out of the server. Turns out, the user-data script configures a local firewall. This goes a bit against the principles of the cloud-native approach, which delegates these concerns to the cloud provider. In fact, in Terraform, I define a firewall and have it automatically applied, based on the labels of the servers. Now, is there a way to make the firewall optional? Cause I think this should not be a concern of the database host.
This may be different if we run your modules on-premise. But my understanding is, that the modules are aimed primarily at the Hetzner cloud.
I know I can use
ufw disable
in thepost_script
option. Just wondering if this needs to be there at all.Appreciate your work. Interested to hear your thoughts.