Hot answers tagged

442

No, Docker containers are not more secure than a VM. Quoting Daniel Shapira: In 2017 alone, 434 linux kernel exploits where found, and as you have seen in this post, kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t ...


85

The patch against Meltdown is kernel only. Docker containers run within the kernel of the host system. This means the resistance against Meltdown depends on the host kernel only. In other words: you don't need patches against Meltdown in the docker image and you cannot patch against Meltdown in the docker image.


76

Saying either a VM or Docker is more secure than the other is a massive over simplification. VM provides hardware virtualization; the hypervisor emulates hardware so that the guest kernel thinks it is running on its own machine. This type of virtualization is easier to isolate from one another. If your primary concern for virtualization is isolation (you ...


46

A user on a Docker host who has access to the docker group or privileges to sudo docker commands is effectively root (as you can do things like use docker to run a privilieged container or mount the root filesystem inside a container), which is why it's very important to control that right. Breaking out of a Docker container to the host is a different game ...


37

At the moment there is no way to easily work out whether to trust specific docker containers. There are base containers provided by Docker and OS providers which they call "trusted" but the software lacks good mechanisms as yet (e.g. digital signing) to check that images haven't been tampered with. For clarification to quote the recently released CIS ...


33

tl;dr: container solutions do not and never will do guarantee to provide complete isolation, use virtualization instead if you require this. Bottom up and top down approaches Docker (and the same applies to similar container solutions) does not guarantee complete isolation and should not be confused with virtualization. Isolation of containers is achieved ...


24

As you correctly stated, Docker uses "Operating-system-level virtualization". You can think of this (if you are a *nix fan) as a fancy form of chroot. By harnessing features and functionality built into the OS, Docker acts as a director for containers. The software's view of the OS is dictated by Docker. The same kernel is used across all containers. So ...


15

This is not a privilege escalation where code gets "only" executed as a higher privileged user. This issue is about execution of code inside the Linux kernel, i.e. the kernel which gets shared between all docker instances and the OS containing the docker instances. This is the highest privilege one could get and at this level one can bypass any kind of ...


13

Docker Containers are Not Inherently “More Secure” But the Ability to Quickly Spin Up—and Destroy—Duplicates in a Cluster Is Very Useful from a Security Standpoint. Okay, lots of other answers here but people tend to forget that sometimes the best tool one can use to secure a web server/application is the ability to quickly redeploy clean code after already ...


12

Whilst the answer from @jens-erat has the correct high-level point that virtualization provides superior isolation to containerization solutions like docker, it is not a black and white setup. On the one hand there have been a number of guest --> host breakouts in virtualization technology (for example the "Venom" vulnerability in virtual floppy device ...


12

I agree with ThoriumBR's answer if we're just comparing a blank VM with a blank Docker container. It should be noted, however, that properly configuring your system such as in Red Hat's Atomic Host mitigates many of those factors and even eliminates some. Also, since Docker started, you can count on one hand the number of the sorts of vulnerabilities ...


12

You can use all of them. Each of these security features have different purposes, and there is actually little overlap. They all function to reduce the damage that a process can cause once it has been compromised. They are all very low-overhead and can be used to significantly improve the security of software. Seccomp is a Linux feature that allows a ...


11

Short answer: Root on the docker container can break out of jail and compromise system. Docker is meant to simplify the life of developers and sysadmins, not about containing programs isolated from each other. There's some safety features backed in, but they are not the main intention. The idea is to ship a container with the application and every pre-...


10

Environment variables are the best way to do this, specifically method 2. Docker, by default, does not allow itself to be run by users other than root. Access to the socket is prohibited. I'd say method 2 is reasonably safe, as out of the box if an attacker has root access (and can poke around in your docker containers) you're already in bad shape. Two ...


10

Theoretically, the isolation of Docker is not quite as strong, because parts of the system are shared (kernel is shared, container has a chroot of the original filesystem, etc). However, for most purposes it's good enough. With chroot, cgroups, etc, and the ability to run containers under an unprivileged account (so root in the container is still limited on ...


9

Docker and LXC are a great concept; isolate potentially vulnerable applications from the rest of the system to limit the damage they can do if something does go wrong. They are not silver bullets, mostly due to limitations in the design of Linux itself i.e. root is root, even inside a chroot. http://www.bpfh.net/simes/computing/chroot-break.html There are ...


9

Trust it as much as any unsigned code that you run on your systems. Containers are just processes with some extra namespace protections on them, so that's all the protections they get. They still talk to the same kernel underneath.


8

One challenge with the environment variable approach is that they are shared with any linked containers (more info here), which may restrict the use of that approach in some setups. Private images as you say are a problem as you're sharing the key to a number of parties and this could also affect your ability to use other related services which would need ...


8

I'd refer you to the CIS Benchmarks for hardening guidelines. The current CIS Benchmark for Docker can be found here. These are an accepted industry standard for baseline hardening. They also offer guidelines for Linux et al, Web servers, DBs, etc.


8

The question is too broad to be answered by a simple "yes" or "no". There are very clear and open attack surfaces for Docker containers: If the attacker is the one who can start containers (i.e., has access to the Docker API), then he immediately, without further action, has full root access to the host. This is well known for years, has been proven, and ...


8

I assume you are concerned about containerized applications running as root. root in container is a risk. It still interacts with the kernel as root. And if an application manages to break out of container, it has root privileges on host. Though, root in container has restricted capabilities compared to root on host. E.g. it does not have capability ...


8

The best way that I've found to execute commands on the underlying host with an exposed Docker socket is Ian Miell's most pointless docker command ever The command looks like this :- docker run -ti --privileged --net=host --pid=host --ipc=host --volume /:/host busybox chroot /host and will essentially drop you straight into a full ...


7

From the docker documentation on container linking, it's possible to see that the standard setup for links is to create an internal network on the docker host which is used by the containers to talk to each other. This network isn't exposed off-host by default so from that perspective it should be secure from network based attackers (i.e. no ports or ...


7

Really the same way you secure anything else. LXC doesn't add anything new to the equation, it's just using cgroups to add more isolation between tasks. And Docker is just LXC automated. Secure your server as you always secure your server. Process isolation, privileges only as necessary, keep software up to date, log management, monitoring ... everything ...


7

It's best to consider a Docker container to be the same as running an application on the host system. There are some attempts to lock down the Docker daemon by removing Linux Kernel capabilities, but this is not really a guarantee. If you do run Docker, there are a few things you can do to help mitigate some of this risk. SELinux - Enabling this will ...


7

A self-answer after a convo on the #docker IRC, PCI DSS v3.2 doesn't state anything about the kind of virtualization that is required, nothing states you should use hardware instead of OS-level virtualization (somebody correct me if I'm wrong). However, traditional (HW) virtualization is a relatively simple piece of code ~100k LOC (allegedly) which is ...


7

Yes there are security risks, especially if you allow arbitrary formats. FFmpeg supports a huge variety of formats, both popular and obscure, for video, audio, and images. Any vulnerability in decoders for any of the numerous formats could be exploited to gain arbitrary code execution. This becomes even more likely given the fact that FFmpeg is written in C, ...


7

Yes, you need to secure the traffic. Reading docs.docker.com: "if you need Docker to be reachable through the network in a safe manner, you can enable TLS by specifying the tlsverify flag and pointing Docker’s tlscacert flag to a trusted CA certificate. In the daemon mode, it only allows connections from clients authenticated by a certificate ...


6

The docker daemon does run as root, as it interfaces with the host operating system in a farily fundamental manner, however that's no different than most/any system daemon that makes use of linux capabilities which require that privilege. This doesn't mean that using docker is insecure, just that you need to be careful with how you use it. Luckily there is ...


6

If anyone comes across this topic, note that a more recent solution might be to use Docker secrets: https://docs.docker.com/engine/swarm/secrets/ It enables Docker Swarm services to safely transmit information such as passwords, SSL certificates, etc., into containers.


Only top voted, non community-wiki answers of a minimum length are eligible