3 ms·

With Docker, how well is the host protected from malicious images?

by TekMol 4y ago

maldev 4y ago
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.
dijit 4y ago
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/ https://docs.docker.com/engine/security/ [1]: https://man7.org/linux/man-pages/man7/capabilities.7.html https://man7.org/linux/man-pages/man7/capabilities.7.html
- password4321 4y ago
  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.
weikju 4y ago
moot when all your workloads are in container images and your host is only there to run the images.

With Docker, how well is the host protected from malicious images?

by TekMol 4y ago

With Docker, how well is the host protected from malicious images?

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.

dijit 4y ago

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/ https://docs.docker.com/engine/security/ [1]: https://man7.org/linux/man-pages/man7/capabilities.7.html https://man7.org/linux/man-pages/man7/capabilities.7.html

password4321 4y ago
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.

weikju 4y ago

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