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