[kayson]

I'd still rather use docker. I don't mind that the daemon runs as root because there are some things that you need root for anyways! Like binding to privileged ports or setting up networks (use `internal: true` and the daemon will automatically set up iptables rules that limit traffic).

I deploy docker compose files with ansible so everything comes with built in security defaults like rootless, dropped caps, no new privileges, etc. I wish more containers supported running read only (its usually pretty easy to add, just overlooked) and distroless (common for go apps, less so otherwise).

There was a pretty good comment on reddit a while back with a list of hardenings for compose files [1]

1. https://www.reddit.com/r/selfhosted/comments/1pr74r4/comment...

[drnick1]

Rootless is definitely the way to go. You can forward ports manually on the host if you really need to use privileged ports. I generally expose my containers through a reverse proxy, running bare metal on the host, and that completely bypasses the privileged port issue.

[nine_k]

Give your binary CAP_NET_BIND_SERVICE capability, and run it as a regular user. Almost no daemons need to run as root.

[merpkz]

That privileged port thing is not true anymore for Docker created containers, since it lowers that limit and unprivileged containers can listen on any port.

  docker run -ti --rm --user 1000:1000 --privileged=false alpine:latest
  ~ $ cat /proc/sys/net/ipv4/ip_unprivileged_port_start
  0
  ~ $ id
  uid=1000 gid=1000 groups=1000
  ~ $ nc -lvp 80
  listening on [::]:80 ...

Also the iptable rules Docker creates is for routing traffic to container with destination NAT, to actually limit traffic you have to do it yourself by inserting rules in DOCKER_USER chain.

[LelouBil]

I get the savings of Distroless, but when you have an issue it's a pain to debug.

[capecodes]

copy the single busybox statically linked binary into a container, and you can create a bunch of symlinks for its tools that you want to use (this is how busybox container itself works)

makes it trivial to do the dhi/rootless thing but do ad-hoc debugging and then remove the debugging tools entirely, leaving no trace/bloat behind (just one file)

[latchkey]

just curious why you'd bind to a priv port inside of a container.

[zerof1l]

This whole privileged port thing is an outdated convention from the time when Linux ran on mainframes. Depending on your use case, it can be perfectly fine to lower it. I have set to `net.ipvX.ip_unprivileged_port_start = 80` on my server so that I can run rootless containers without extra privileges and have them bind to ports 80 and up.

[bityard]

Nits: It's a Unix convention (not just Linux), and Unix traditionally ran on minicomputers (not mainframes). Mainframes had their own specialized OSes, although some could run Unix in a partition or virtual machine.

[nine_k]

I think that "Linux ran on mainframes" was said in jest. Even though Linux runs on mainframes pretty well even now.

[bubblebeard]

I've read that privileged ports was created as a trust model, so users connecting to a service using a privileged port would know that service was started by root on that server and therefore could be trusted. I always felt this was a bit wierd though, maybe I was missinformed, or maybe priviliged ports was already a thing and was just leveraged this way?

[dboreham]

lol the before times when Linux ran on mainframes.

It does run on IBM 370 type mainframes, but that port was done years after it first ran on the 386, and isn't in any way relevant to low port numbers.