fix(compose): bind datastore ports to loopback + harden probe - #300
Merged
telivity-otaip merged 2 commits intoAug 11, 2026
Merged
Conversation
…n pack docker-compose.yml publishes Postgres on 5432 and Redis on 6379 across all interfaces, with the credentials set in the same file. Docker's published ports bypass host firewalls -- ufw and firewalld rules sit behind Docker's own chain -- so following the quick start on a public host yields an internet-reachable Postgres with default credentials even when a firewall is correctly configured. Binds postgres, redis and minio to 127.0.0.1. Host tooling (psql, a GUI, the MinIO console) still connects exactly as before; only external interfaces stop being served. Adds compose:datastores-loopback to the harden pack's local probes so a regression is caught pre-go-live, since that pack is already where "would this be safe on a public host" belongs. Keycloak under the auth profile publishes 8080 with admin/admin and is deliberately left alone here -- same shape, but it may cut across intended remote use of that profile.
Maintainer polish on the datastore loopback change so the MinIO console cannot regress to all-interfaces independently of the S3 API port. Co-authored-by: telivity-otaip <telivity-otaip@users.noreply.github.com>
telivity-otaip
approved these changes
Aug 11, 2026
telivity-otaip
left a comment
telivity-otaip
left a comment
Collaborator
There was a problem hiding this comment.
Excellent catch on Docker published ports bypassing host firewalls with default datastore creds. Thank you, Charles — merging with full credit to you.
Small maintainer polish on your PR: probe now also covers minio :9001 so the console can’t regress independently.
Keycloak :8080 — same exposure shape you flagged. Not changing it inside your PR; opening a follow-up immediately that binds it to loopback + probe coverage, credited to your note in #300.
3 tasks
Collaborator
|
Follow-up for the Keycloak |
telivity-otaip
added a commit
that referenced
this pull request
Aug 11, 2026
Follow-up to #300: same Docker publish / default-credential exposure shape Charles flagged for Keycloak :8080. Localhost Keycloak and the dashboard auth profile still work; remote access needs a tunnel or an explicit override. Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: telivity-otaip <telivity-otaip@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
docker-compose.ymlpublishes Postgres on5432:5432and Redis on6379:6379— all interfaces — with the credentials set in the same file (haip/haip).The reason this is worth more than a style nit: Docker's published ports bypass host firewalls. ufw and firewalld operate on chains that Docker's own rules sit in front of, so an operator who has correctly configured a firewall still ends up with an internet-reachable Postgres carrying default credentials the moment they run
docker compose upon a public host. Following the quick start exactly is enough to get there.The change
Bind
postgres,redisandminioto127.0.0.1. The dev workflow is unaffected —psql, a GUI client, and the MinIO console all still connect from the host exactly as before. Only external interfaces stop being served.I've also added
compose:datastores-loopbacktoops/harden/cli/probes/local.mjs, since the harden pack is already the right home for "would this be safe on a public host" — this way a regression gets caught pre-go-live rather than by a port scan.Probe verified both directions (I don't have Node locally, so I checked the pattern against both trees rather than claiming a test run): it flags all three services on the current file, and passes cleanly on the patched one. A check that has only ever passed isn't a check.
Deliberately not changed — flagging rather than presuming
Keycloak under the
authprofile publishes8080withKEYCLOAK_ADMIN=admin/KEYCLOAK_ADMIN_PASSWORD=admin. Same exposure shape, but changing it may cut across how you intend that profile to be used remotely. Happy to follow up separately if you'd like it treated the same way.Found while running HAIP self-hosted with auth on — the harden pack made that path a lot smoother, so this is meant as a small addition to it rather than a criticism of it.