Comment by acatton

It's hard to point to a canonical documentation, it's more institutional knowledge that is gained over years of practice. It's a little bit as if you asked "could you point at the documentation to secure a linux server?"

There is none really. Usually, some beginner wrote a blog post that basically says "install fail2ban" and that's how many people consider their linux server "secured". But there is much more than that. For example, "put your entire firewall to DENY, and only open what is really necessary." Or "put SSH behind spiped[1] or wireguard". Or "Harden the maximum of your systemd units"[2]. Or "don't do chmod 777, try to understand why it doesn't work." And so on and so on...

For docker, it's the same, I'm not a docker fan, as I mostly use podman, which allows to runs container as different users. In general for security, I would recommend podman running as non-root, but if you insist to run Docker, here are a few places where you could start to harden it:

* Look into enabling and enforcing SELinux policies or Apparmor profiles on your host: https://www.mankier.com/8/container_selinux or https://docs.docker.com/engine/security/apparmor/

* Look into root-less docker daemon: https://docs.docker.com/engine/security/rootless/

* Make sure you don't run any priviledged container, if you do, look into alternatives to run them in non-priviledged mode

Docker has a page about security, it looks like they echo a lot of things I'm saying: https://docs.docker.com/engine/security/ . Avoid GRSEC though, it's basically security theater. They mention docker seccomp profiles[3], which I've never used, but is definitely a good idea when hardening untrusted code.

Also, hardening the OS that you're running docker on (using the things I mentioned earlier about Linux) won't hurt.

[1] https://www.tarsnap.com/spiped.html

[2] https://ruderich.org/simon/notes/systemd-service-hardening

[3] https://docs.docker.com/engine/security/seccomp/