All geek questions in one place

Docker Best Practices for Security

Most of the Dockerfiles you find on the Internet build and run the software as root! That should scare everyone, right? ... but it doesn't seem like that ...

So pb is starting the server as root, even in the container, DANGEROUS, because the root inside the container is not at all different from the root outside the container.

One solution is to create the Dockerfile correctly using the USER statement, for example this example for a torque relay .

Another solution is to use the "linux username space" to "map" the UID / GID inside the container to the UID / GID outside the container. for example, root (uid = 0) inside the container can be mapped to your personal user account inside the host, so the files created on the shared volume have good permissions.

So my question is: what is the best practice when it comes to security with Docker? run code as non-root (for example, the USER statement in the Docker file)? Or using "username spaces"? Or eventually (or optionally) using selinux and / or AppArmor?

Thanks:)

+5
source share
3 answers

Quote Solomon Hicks

Hi everyone, I am a supporter of Docker. As others have already pointed out, this does not work on 1.0. But it could be.

Remember that we are not currently claiming that Docker out of the box is suitable for storing untrusted programs with root privileges. Therefore, if you think "pfew, a good thing that we upgraded to 1.0, or we were toasts," you need to change your basic configuration now. Add an apparmor or selinux application, group trust groups to separate machines, or, ideally, do not provide root access to the application.

So how effective are the methods, give them namespaces and apparmor or selinux if you are serious about security. This says that many people don’t care about additional troubles (for better or for worse), so you see that many people don’t get into trouble. Setting permissions for users in files inside the container (especially those installed as volumes) sometimes becomes difficult, and many people skip the extra overhead.

+3
source

In addition to SELinux, Apparmour, GRSEC, cgroups provides an additional advantage of isolation and limitation of the use of container resources, if it is configured with caution, this helps to prevent infection of one hacked container in another container.

+1
source

Best practice is to follow all three options mentioned at the end of the question together, in accordance with the CIS security criteria:

  • Non-root internal container (section 4.1)
  • Enable user namespaces (section 2.8)
  • Enable MAC ie SELinux or AppArmor in enforcement mode (section 5.2)

Links: https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.12.0_Benchmark_v1.0.0.pdf

+1
source

Source: https://habr.com/ru/post/1208157/

More articles:


All Articles