In this video, learn what level of security is built into the Docker Engine, including topics like kernel namespaces, cgroups, the attack surface, and Linux kernel capabilities.
- [Instructor] For the Docker Certified Associate exam, the study guide says that you should be able to describe the default Docker engine security. So, just by default, when you install Docker server, what level of security does it provide? Let's explore that a little bit in this video. First off, you have kernel namespaces. Kernel namespaces are created when a container is run. When every container is run, a namespace is created, and so is a control group, which we'll talk about in just a moment.
Container processes cannot see or affect other processes because they're in their own namespace. So if you're in a container, you do a ps, you can't see other processes that are running on the host or other processes running in other containers, nor can you affect those processes in any way. Each container also has its own network stack. So if I do an ifconfig and I list out the network configuration, that's the network configuration just for that container. And I can change that network configuration without changing the host's network configuration or other containers' network configuration as well.
The second thing that's created, as I said, when you run a container, besides a kernel namespace, is a control group. These are also called cgroups, and what a cgroup does is it provides resource accounting and limiting and it ensures that no containers exhaust the host's resources. So if you have a malicious container or maybe a malicious attacker has gained access to a specific container and tries to spawn off hundreds or thousands of processes inside that container to try to take down other containers or maybe take down the container host, it's the control groups, or cgroups that prevent this from happening.
The third thing I want to talk about, when it comes to the default Docker engine security stance, is the Docker daemon attack surface. The attack surface for the Docker daemon is small, but you need to take appropriate security measures. So you should only run Docker on a host. You shouldn't run Docker and many other production applications. For example, if you're going to run Docker, run Docker on that host, and that should be the only application running on that host except for the applications that run inside the containers.
It's just like virtualization. You don't run a hypervisor on a host and then multiple other applications as well. If you want to run those applications, you run them inside the virtual machines, or in this case, the containers. You also should only let trusted users control the Docker daemon because the Docker daemon is running with root privileges, so keep that in mind. And finally, keep in mind the Linux kernel capabilities. Docker runs containers with restricted capabilities, and this is actually really cool because even, for example, operating system containers, they don't get full root privileges even though they are their own operating system.
All of what I just discussed and more is available on the Docker web site in the Docker security section, and in fact if you scroll down here there's a lot more information that you can read about when it comes to learning the default stance of the Docker engine as it pertains to security.