The host should be protected in regards to code execution (Assuming theirs no escape).

The big issues come in the fact that you may pass in proprietary/confidential files, for example Code, which is now at risk of being leaked and the company faces extortion. Or you have a network configuration where the malware can pivot onto another server and now your whole environment is exposed to risk.

It's controversial because there are definitely a contingent of people who really want to believe docker adds a realistic layer of security isolation.

But no credible security researcher, security engineer or even Docker the company itself has ever considered Docker the container runtime to be a security mechanism (well, outside of the fact it's leveraging kernel namespaces)[0].

There's also a lot of really bad security hygiene when it comes to running docker images even if they could be secure: Docker runs programs by default as root and this gives programs quite a lot of possibility to escape a container, many containers are used in CI (DinD) which exposes the host docker daemon, most containers are not run with `--cap-drop all` which drops capabilities from the kernel[1], I have never seen a container run with `--security-opt=no-new-privileges` which would prevent escalating privileges using `setuid` or `setgid` binaries (leading to the same issue as running everything as root), etc, etc, etc;

[0]: https://docs.docker.com/engine/security/

[1]: https://man7.org/linux/man-pages/man7/capabilities.7.html

Thanks for pointing to these options; is there a list you can recommend of everything that should be done (hopefully updated regularly)? It is quite the arms race.

moot when all your workloads are in container images and your host is only there to run the images.