Self hosting port exposure

[davidfiala]

I've made the following modifications to decrease the potential exposure of services during self hosting.

I'd like to know if there's any reason not to apply them (side effects I didn't realize), and whether we should PR them in.

In .env, I do not want the 3001 and 3002 exposed to any interface except for my reverse proxy on the host:

# Before:
HOST_BACKEND_PORT="3001:3001"
HOST_CLIENT_PORT="3002:3002"
# After:
HOST_BACKEND_PORT="127.0.0.1:3001:3001"
HOST_CLIENT_PORT="127.0.0.1:3002:3002"

Likewise, I do not want clickhouse exposed outside of the private/internal docker network, so I've removed their exposed ports.

$ git diff docker-compose.yml
diff --git a/docker-compose.yml b/docker-compose.yml
index d1d4029..963043b 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -22,9 +22,9 @@ services:
   clickhouse:
     container_name: clickhouse
     image: clickhouse/clickhouse-server:25.4.2
-    ports:
-      - "8123:8123"
-      - "9000:9000"
+#    ports:
+#      - "8123:8123"
+#      - "9000:9000"
     volumes:
       - clickhouse-data:/var/lib/clickhouse
       - ./clickhouse_config:/etc/clickhouse-server/config.d

[smileBeda]

The default .env already uses this approach: https://github.com/rybbit-io/rybbit/blob/ca79d33ce97e31ae8b2d197ad73ce56ed916dd88/.env.example#L14C1-L15C32

Not exposing clickhouse (or any other port) unless on the shared network should never be an issue in Docker, as long as the network is shared amongst the containers that need access to it.

This is de-facto the correct way of using Docker, and resolves the misconception of Docker being "unsafe" because it bypasses UFW and opens ports which is often brought up as a huge issue of docker. The huge issue here is that 99.99% of all suggested docs, install methods etc (even docker doc itself) does not use that approach as the default, and rather uses the "it just works" approach of simply opening ports.

From what I see in basically all other self hosted or else docker related docs, this is always how it is documented (opening ports)
As such I would say probably just to keep the mainstream, it would be OK to keep that same approach in rybbit, however, on the other hand, it might be the moment to actually promote security, and as such, update the Documentation and files to reflect this.

I have moved this to a discussion, so the Devs can chime in on here (and perhaps other users) to make a decision about it.
I am in favor of doing it "right", all the way. Thus, upvoted this.

[davidfiala]

Thanks for the reply.

Backend/Client port binding:

My HOST_BACKEND_PORT and HOST_CLIENT_PORT were set by setup.sh lacking the 127.0.0.1: prefix because I'd used --no-webserver. Relevant code here. Given that the webserver/proxy is likely to be on the same host as the docker containers, I'd advocate for locking it down to 127.0.0.1.

Clickhouse

Clickhouse wasn't using an internal network, so AIUI, docker is exposing those ports publically.

To check this behvior, docker-compose.yml:

version: '3.9'

services:
  test-server:
    image: python:3.11-alpine
    container_name: test-server
    command: >
      sh -c "python3 -m http.server 8000 --bind 0.0.0.0"
    ports:
      - "8000:8000"

port 8000 is exposed and operational on the host's 0.0.0.0

---

AIUI, the clickhouse is already shared within the compose's virtual network. So exposing on the public host IP is unnecessary because docker will already link the containers in the same compose together.

Please let me know if I misunderstood you in any way. I think the original issue regarding ports still remains too-broadly-open as-is.