Replies: 1 comment
|
Also you can omit the port exposure overall, and let caddy reach the containers internal port example: services:
bentopdf:
image: ghcr.io/alam00000/bentopdf-simple:latest
container_name: bentopdf
restart: unless-stopped
user: 1000:1000
read_only: true
security_opt:
- no-new-privileges:true
cap_drop:
- ALL
tmpfs:
- /etc/nginx:uid=1000,gid=1000,rw,noexec,nosuid,nodev
- /var/cache/nginx:uid=1000,gid=1000,rw,noexec,nosuid,nodev
- /var/lib/nginx/tmp:uid=1000,gid=1000,rw,noexec,nosuid,nodev
# - /var/run:uid=1000,gid=1000,rw,noexec,nosuid,nodev
networks:
- dockernetwork
# ports:
# - 8080:8080
environment:
- TZ=${TZ}
# - DISABLE_TOOLS="edit-pdf,sign-pdf,encrypt-pdf" # Tool IDs are the page URL without .html
# - DISABLE_IPV6=true # Incompatible with read_only, as it modifies nginx.conf at startup
healthcheck:
test: ['CMD', 'wget', '--spider', '-q', 'http://localhost:8080']
interval: 30s
timeout: 10s
retries: 3
networks:
dockernetwork:
external: trueCaddyfile: |
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.
First of all, thank you for publishing these templates. They are among the most security-conscious Docker Compose examples I've found and the extensive comments explaining the reasoning behind each decision make them a great learning resource.
I have been doing the same pattern for years and spending a lot of time digging through official repositories, GitHub issues, discussions and community forums to find caveats and workarounds to be able to run my containers with the most hardened configs, So, here are few suggestions that you may consider or discuss:
1.
ipc: privateAs far as I understand, Docker's default IPC mode is already
private, so this line is redundant unless the Docker daemon has been configured with a different default. Omitting it would slightly reduce clutter while keeping the same behavior.2. Resource limits
The
deploy.resourcessections are well thought out, but they make the compose files considerably longer.Many users and myself actually already monitor CPU, memory and PID usage with tools such as Beszel, Prometheus, Grafana, Netdata, etc. and prefer to size containers based on observed usage instead of predefined limits.
It's easy to present status and percentages when the resources are relative to the whole system resource.
Perhaps these limits could be presented as an optional hardening section or documented separately, allowing users to opt in if they want resource enforcement.
3. Running services as a non-root user
Many container images support running with a fixed unprivileged user such as:
often together with:
when the required writable paths are provided.
For example, my Adguardhome runs perfectly like this: (also caddy, and many others as I will show below ...)
Also, Postgres and Redis in my Nextcloud stack
I understand this is image-dependent and isn't universally applicable but it may be worth documenting these opportunities where they exist.
Actually I made a matrix of my services and which ones accepts hardened configs after long time of tinkering
no-new-privilegescap_dropcap_addtmpfs1000:1000ALL1000:1000ALLNET_BIND_SERVICE1000:1000ALL1000:1000ALL/etc/nginx:uid=1000,gid=1000,rw,noexec,nosuid,nodev/var/cache/nginx:uid=1000,gid=1000,rw,noexec,nosuid,nodev/var/lib/nginx/tmp:uid=1000,gid=1000,rw,noexec,nosuid,nodev1000:1000ALLNET_BIND_SERVICE1000:1000ALL1000:1000ALL1000:1000ALL1000:1000ALLNET_ADMIN1000:1000ALL1000:1000ALL/tmp:rw,noexec,nosuid,nodev1000:1000ALL/tmp:rw,noexec,nosuid,nodev1000:1000ALL1000:1000ALL/tmp:rw,noexec,nosuid,nodev,uid=1000,gid=1000/run:rw,nosuid,exec,nodev,uid=1000,gid=10001000:1000ALL1000:1000ALL1000:1000ALL1000:1000ALL1000:1000ALLALL/tmp:rw,noexec,nosuid,nodev/run:rw,noexec,nosuid,nodevALLCHOWNDAC_OVERRIDEFOWNERSETGIDSETUIDPUID=1000PGID=1000ALLNET_RAWNET_ADMINSYS_MODULECHOWNDAC_OVERRIDE/run:rw,noexec,nosuid,nodevThe only service that I struggle to implement these measures on is Nextcloud, it has too many moving parts and always fails to accomaodate these configs, and I'm with you that AIO is just not meant to be controlled or hardened, So I accepted to use Linuxserver image LSIO as they are very reputable and actually make security updates even faster than the community image of
Nextcloud Dockerand while both initially runs as root then drop privileges , I don't see a difference except trusting the source of image.Overall, these are only minor suggestions. I think this repository is one of the best documented and most security-focused Docker Compose collections available and I appreciate the amount of work that has clearly gone into it.
Thanks again for sharing it! And please I'm welcoming any suggestions or correction to my current setup.
All reactions