Hot answers tagged

433

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 ...


87

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.


75

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 ...


38

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 ...


31

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 ...


12

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 ...


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-...


11

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 ...


11

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 ...


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

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.


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 ...


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

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

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 ...


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

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

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

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 ...


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, ...


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.


6

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 ...


6

In essence, I argue it is the same question as whether open source software is trustworthy. But I think the risk of using community Docker containers is somewhat higher at present than the risks of using open source software. First, as you mentioned, there is no signing and verification now. Good open source packaging systems today include this, at least ...


6

Docker guys have recently introduced their native solution for this: https://blog.docker.com/2017/02/docker-secrets-management/ The usage pattern is: $ echo "This is a secret" | docker secret create my_secret_data - $ docker service create --name="redis" --secret="my_secret_data" redis:alpine The unencrypted secret is then mounted into the container in ...


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