Docker Compose: Hardcoded Credentials, No Redis Auth, Production Proxy Co-located
Local dev compose hardcoded Postgres credentials, ran Redis with no auth bound to 0.0.0.0, and co-located a production read-replica proxy alongside dev services. Partially fixed by moving prod proxies into a separate compose file bound to localhost.
Description
# L12-L13, hardcoded Postgres password in version controlPOSTGRES_PASSWORD: lentille-de-fresnel# L29-L33, Redis with no authentication, bound to 0.0.0.0redis:ports:- "6379:6379"# L74-L87, PRODUCTION read-replica proxy in local dev composegcp-sql-proxy-prod-replica:volumes:- ./credentials/dripster-backend-prod.json:/config
Impact
Co-locating a production database proxy with local development services materially raises the risk of accidental cross-environment access (a misconfigured query targets prod read-replica). Hardcoded credentials and unauthenticated Redis are typical local-dev convenience items but become real risks if the file is ever copied to a less-isolated environment.
Recommendation
Move production proxy to a separate compose file. Add Redis requirepass. Bind to 127.0.0.1.
Resolution
Partially fixed in PR #3746, prod read-replica and sandbox SQL proxies were moved to a separate docker-compose.remote-db.yml and bound to 127.0.0.1 only. Local-dev Postgres password and Redis no-auth were left as-is by team decision (no LAN exposure, no prod data).
