emilandClaude Opus 4.7
79e1dc4144
Yesterday's prod incident exposed postgres on 0.0.0.0:5432 with the
default 'postgres:postgres' credentials. A scanner ransomware bot
brute-forced it and dropped the database (left a readme_to_recover
note). We restored from a pre-incident dump and the user data is back,
but the underlying weakness was in this docker-compose.yml.
Changes:
- Remove `ports: "5432:5432"` from the postgres service entirely.
Postgres is reachable only via the internal docker network. For
ad-hoc admin access, use an SSH tunnel:
`ssh -L 5432:localhost:5432 deploy@<host>`
- POSTGRES_PASSWORD now reads from `${POSTGRES_PASSWORD:-postgres}`
via env interpolation. Prod `.env` (not in repo) provides the real
value; local dev gets the `postgres` fallback so `docker compose up`
still works without setup.
- Remove the no-longer-needed DATABASE_URL override in the app service
`environment:` — `env_file: .env` already supplies it.
After this lands, the deploy pipeline will rsync the new compose.yml,
recreate containers with no exposed pg port, and substitute the strong
password from .env at container start. Volumes persist, data intact.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
