Server: Docker Compose unnecessarily exposes Postgres to Host - which may cause unwanted exposure of the DB

[pano9000]

Operating system

Linux

Joplin version

3.0.1-beta

Desktop version info

No response

Current behaviour

When you use the "non-dev" docker-compose.server.yml docker compose file, it will – by default – also expose the postgres database to the host – which (for a productive environment) is a) totally unnecessary and b) currently also is a potential unwanted exposure of your DB

I would argue, that in a productive environment you would not want the database to be accessible externally.
-> after all you only want to interact with the Joplin Server and access it externally.
you very likely don't want to manage/maintain the database directly remotely: I would suppose would more than likely rather start an ssh session to the server and do your postgres maintenance locally.

Generally speaking, you could say "just hide the database behind a firewall", but unfortunately there is a bit of a tricky situation:
ufw – the firewall utility of Debian/Ubuntu – and Docker are not playing together nicely. Bluntly speaking:
With the default Docker settings, anything you expose in Docker will essentially bypass your ufw rules and therefore potentially be available to the public.

This is even pointed out in the Docker docks:
https://docs.docker.com/engine/network/packet-filtering-firewalls/#docker-and-ufw

Some additional info also in this blog post:
https://vpetersson.com/2014/11/03/the-dangers-of-ufw-docker.html

I personally was also noticing this, after using the docker-compose file on my publicly accessible VPS and noticing that I could connect to the Postgres service remotely from my home computer - even though my ufw rules only allowed certain ports (i.e. my attempt should've been filtered out).

The easiest "fix" would be to NOT expose the ports – by default – to the host for the DB part of the compose file, by simply removing the "ports" section.

This does not affect the Joplin server at all since within the Docker Network environment they can still communicate with each other.

Expected behaviour

No response

Logs

No response