3 ms·
(Same discussion as on lobste.rs) Thank you for this link, I've only seen the initial CVE announcement. > This is not FUD [...] The site is practicing FUD, i
by miduil 7y ago
(Same discussion as on lobste.rs)
Thank you for this link, I've only seen the initial CVE announcement.
> This is not FUD [...]
The site is practicing FUD, it accomplishes communicating a message in an untruthful fashion by mixing two different things into one. (Just check out their stack overflow links, it is not clear if they are talking about root or `--privileged`)
People are confused wether `docker root == host system root` and this site doesn't help them to get a better understanding whether or not it is the case. (It isn't) Plus it misses what its main goal should be, running a Secure Docker environment.
You are talking about a previous exploit, not a permanent issue. Keeping your host system up to date and additional hardenings is always going to be necessary in exposed environments.
> Use Docker containers with SELinux enabled (--selinux-enabled). This prevents processes inside the container from overwriting the host docker-runc binary.
Authors recommendation is also using SELinux, this also helped with outer Docker/Kernel related vulnerabilities in the past. Why isn't the page even mentioning this?
---
I think it is important to give a proper outlook on how problematic things are and not to confuse people with super high expectations. You often end up running containers that you have only little control about.
1. Avoiding root in self-built containers is definitively the way to go, since it reduces (unnecessary) attack surface, but
1. It requires some glue code
2. Might slow down your builds (`Dockerfile` multistage `cp --from=0 /app /app` loses permissions, requires chown afterwards)
2. Avoiding root in CI/CD is nearly impossible
1. many package managers won't work
2. some capabilities to test things (sshd for testing ansible scripts for example)
3. can you use kaniko for building Docker images from within Docker without root?
3. Harden your Docker host
1. Use SELinux
2. Use monitoring
3. Drop capabilities that aren't necessary (NET_BIND_SERVICE, NET_RAW, ...)
4. Use docker network separation
5. Frequent system updates
4. Keep yourself up-to-date, especially if you are running an exposed environment
Just googled and this is rather more helpful:
- https://dev.to/petermbenjamin/docker-security-best-practices-45ih https://dev.to/petermbenjamin/docker-security-best-practices...
- https://blog.aquasec.com/docker-security-best-practices https://blog.aquasec.com/docker-security-best-practices
- https://sysdig.com/blog/7-docker-security-vulnerabilities/ https://sysdig.com/blog/7-docker-security-vulnerabilities/
- https://github.com/docker/docker-bench-security https://github.com/docker/docker-bench-security