A tested hardened compose overlay for self-hosting, if that's useful to anyone #9445
HersheyxBar
started this conversation in
Show and tell
Replies: 1 comment
|
Hello, could you share your compose file please? to better understand what you changed |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hey, I run a self-hosted CE v1.3.1 deploy and spent a couple weeks pushing it well past the default compose for a school project: dropping caps, read-only rootfs, split networks, docker secrets, MinIO over TLS. The shipped defaults are honestly reasonable for most self-hosters, this was me deliberately over-tightening things to see what it takes, and I figured the sharp edges were worth sharing for anyone attempting the same.
Most of the friction came from the hardening itself, not from anything in the repo. A few notes for the next person:
Once you drop all caps, a few services need some back to boot: Postgres chowns its data dir (CHOWN, DAC_OVERRIDE, FOWNER, SETGID, SETUID), RabbitMQ uses su-exec (SETGID, SETUID), the nginx frontends chown their cache dir (CHOWN). Read-only rootfs is the same story, it needs tmpfs alongside it (/var/cache/nginx for nginx, /code/plane/static-assets for the api since collectstatic runs on boot).
Network membership caught me twice, and the first one cost me more time than anything else here. The proxy needs to be on both the edge and app networks. On edge alone every request 502s because it can't resolve the app services. And plane-live opens a Redis connection at startup, so it needs the data network too, not just edge and app.
One genuine heads-up rather than a me-problem: RabbitMQ refuses to start with RABBITMQ_DEFAULT_PASS_FILE set, it treats the _FILE vars as deprecated. So if anyone else tries moving the stack onto docker secrets, that's the one service you can't, you'd need a rabbitmq.conf.
For MinIO over TLS the cert SAN has to include plane-minio, and if it's self-signed the api and workers need both AWS_CA_BUNDLE and REQUESTS_CA_BUNDLE pointed at the CA or boto3 won't trust it.
Two smaller traps. Overriding entrypoint: in compose clears the image CMD, my live container sat exiting 0 with no logs at all until I put command: back explicitly. And once HTTPS origins are on, a healthcheck probing 127.0.0.1 comes back 400 so the container looks unhealthy when it's actually fine, it needs a Host header matching the configured origin.
I've got the whole overlay working now, all containers healthy behind TLS with segmented networks. If a hardened opt-in overlay is ever something you'd consider for the self-hosting docs, I'm happy to open a PR and you can take or leave whatever fits. Totally understand if the current defaults are where you want them.
Separately, I filed a security advisory a while back (GHSA-v7hq-qvxc-4m74) that's still in triage. Cross-tenant authz bug, medium sev, full details and a suggested fix are in the advisory. Would appreciate a maintainer taking a look when there's time. I've got a patch and regression tests ready to PR. Thanks!
All reactions