1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00

Fixed #6545 - Updated Security article

Docker-DCO-1.1-Signed-off-by: James Turnbull <james@lovedthanlost.net> (github: jamtur01)
This commit is contained in:
James Turnbull 2014-06-19 12:07:39 -05:00
parent 874698cb4a
commit bf69b773ec

View file

@ -17,15 +17,10 @@ There are three major areas to consider when reviewing Docker security:
## Kernel Namespaces ## Kernel Namespaces
Docker containers are essentially LXC containers, and they come with the Docker containers are very similar to LXC containers, and they come with
same security features. When you start a container with the similar security features. When you start a container with `docker
`docker run`, behind the scenes Docker uses run`, behind the scenes Docker creates a set of namespaces and control
`lxc-start` to execute the Docker container. This groups for the container.
creates a set of namespaces and control groups for the container. Those
namespaces and control groups are not created by Docker itself, but by
`lxc-start`. This means that as the LXC userland
tools evolve (and provide additional namespaces and isolation features),
Docker will automatically make use of them.
**Namespaces provide the first and most straightforward form of **Namespaces provide the first and most straightforward form of
isolation**: processes running within a container cannot see, and even isolation**: processes running within a container cannot see, and even
@ -55,10 +50,9 @@ ago), namespace code has been exercised and scrutinized on a large
number of production systems. And there is more: the design and number of production systems. And there is more: the design and
inspiration for the namespaces code are even older. Namespaces are inspiration for the namespaces code are even older. Namespaces are
actually an effort to reimplement the features of [OpenVZ]( actually an effort to reimplement the features of [OpenVZ](
http://en.wikipedia.org/wiki/OpenVZ) in such a way that they http://en.wikipedia.org/wiki/OpenVZ) in such a way that they could be
could be merged within the mainstream kernel. And OpenVZ was initially merged within the mainstream kernel. And OpenVZ was initially released
released in 2005, so both the design and the implementation are pretty in 2005, so both the design and the implementation are pretty mature.
mature.
## Control Groups ## Control Groups
@ -82,7 +76,7 @@ started in 2006, and initially merged in kernel 2.6.24.
## Docker Daemon Attack Surface ## Docker Daemon Attack Surface
Running containers (and applications) with Docker implies running the Running containers (and applications) with Docker implies running the
Docker daemon. This daemon currently requires root privileges, and you Docker daemon. This daemon currently requires `root` privileges, and you
should therefore be aware of some important details. should therefore be aware of some important details.
First of all, **only trusted users should be allowed to control your First of all, **only trusted users should be allowed to control your
@ -114,8 +108,9 @@ socket.
You can also expose the REST API over HTTP if you explicitly decide so. You can also expose the REST API over HTTP if you explicitly decide so.
However, if you do that, being aware of the above mentioned security However, if you do that, being aware of the above mentioned security
implication, you should ensure that it will be reachable only from a implication, you should ensure that it will be reachable only from a
trusted network or VPN; or protected with e.g. `stunnel` trusted network or VPN; or protected with e.g. `stunnel` and client SSL
and client SSL certificates. certificates. You can also secure them with [HTTPS and
certificates](/articles/https/).
Recent improvements in Linux namespaces will soon allow to run Recent improvements in Linux namespaces will soon allow to run
full-featured containers without root privileges, thanks to the new user full-featured containers without root privileges, thanks to the new user
@ -199,15 +194,18 @@ container, it will be much harder to do serious damage, or to escalate
to the host. to the host.
This won't affect regular web apps; but malicious users will find that This won't affect regular web apps; but malicious users will find that
the arsenal at their disposal has shrunk considerably! You can see [the the arsenal at their disposal has shrunk considerably! By default Docker
list of dropped capabilities in the Docker drops all capabilities except [those
code](https://github.com/dotcloud/docker/blob/v0.5.0/lxc_template.go#L97), needed](https://github.com/dotcloud/docker/blob/master/daemon/execdriver/native/template/default_template.go),
and a full list of available capabilities in [Linux a whitelist instead of a blacklist approach. You can see a full list of
available capabilities in [Linux
manpages](http://man7.org/linux/man-pages/man7/capabilities.7.html). manpages](http://man7.org/linux/man-pages/man7/capabilities.7.html).
Of course, you can always enable extra capabilities if you really need Of course, you can always enable extra capabilities if you really need
them (for instance, if you want to use a FUSE-based filesystem), but by them (for instance, if you want to use a FUSE-based filesystem), but by
default, Docker containers will be locked down to ensure maximum safety. default, Docker containers use only a
[whitelist](https://github.com/dotcloud/docker/blob/master/daemon/execdriver/native/template/default_template.go)
of kernel capabilities by default.
## Other Kernel Security Features ## Other Kernel Security Features
@ -222,17 +220,16 @@ harden a Docker host. Here are a few examples.
- You can run a kernel with GRSEC and PAX. This will add many safety - You can run a kernel with GRSEC and PAX. This will add many safety
checks, both at compile-time and run-time; it will also defeat many checks, both at compile-time and run-time; it will also defeat many
exploits, thanks to techniques like address randomization. It exploits, thanks to techniques like address randomization. It doesn't
doesn't require Docker-specific configuration, since those security require Docker-specific configuration, since those security features
features apply system-wide, independently of containers. apply system-wide, independently of containers.
- If your distribution comes with security model templates for LXC - If your distribution comes with security model templates for
containers, you can use them out of the box. For instance, Ubuntu Docker containers, you can use them out of the box. For instance, we
comes with AppArmor templates for LXC, and those templates provide ship a template that works with AppArmor and Red Hat comes with SELinux
an extra safety net (even though it overlaps greatly with policies for Docker. These templates provide an extra safety net (even
capabilities). though it overlaps greatly with capabilities).
- You can define your own policies using your favorite access control - You can define your own policies using your favorite access control
mechanism. Since Docker containers are standard LXC containers, mechanism.
there is nothing “magic” or specific to Docker.
Just like there are many third-party tools to augment Docker containers Just like there are many third-party tools to augment Docker containers
with e.g. special network topologies or shared filesystems, you can with e.g. special network topologies or shared filesystems, you can
@ -243,7 +240,7 @@ affecting Docker's core.
Docker containers are, by default, quite secure; especially if you take Docker containers are, by default, quite secure; especially if you take
care of running your processes inside the containers as non-privileged care of running your processes inside the containers as non-privileged
users (i.e. non root). users (i.e. non-`root`).
You can add an extra layer of safety by enabling Apparmor, SELinux, You can add an extra layer of safety by enabling Apparmor, SELinux,
GRSEC, or your favorite hardening solution. GRSEC, or your favorite hardening solution.