Docker Security-official documents [translate]

Docker Security-official documents [translate]

This article was translated from the official Docker document: https://docs.docker.com/articles/security/

There are three key areas to consider when reviewing the security of Docker:
The intrinsic security of the container is implemented by the kernel namespace and cgroup;
The attack surface of the Docker daemon itself;
? Reinforce the kernel security features and how they interact with the container.

Kernel namespace Kernel Namespace

Docker containers are very similar to LXC containers, and they all have similar security features. When you start a container with "Docker run", background Docker creates a set of namespaces and control groups for the container.
namespaces provide the first and simplest form of isolation: processes running in one container do not see processes running in another container or in the host system, or even fewer effects between them.

Each container also has its own network protocol stack, which means that the container does not have privileged access to another container's socket or interface. Of course, if the host system is set up, therefore, the containers can go through their respective network interfaces

Interactions-just as they can interact with external hosts. When you specify a public port for your container or use a link, IP traffic is allowed between containers. They can ping each other, send/receive UDP packets, and establish

TCP connections, but can be restricted if necessary. From a network architecture, all containers on a given Docker host are seated on the bridge interface. This means that they just want to connect things through a common Ethernet switch

Not much, no less.

How does the code mature to provide kernel namespaces and private networks? The kernel version of the kernel namespace is described between 2.6.15 and 2.6.26. This means, since July 2008 (2.6.26 release date, now 5 years ago), named

Space codes have been implemented and reviewed on a large number of production systems. And more: Design-inspired namespace code, even older. Namespaces are actually intended to be re-implemented because they may be merged into the mainstream kernel so

The openvz characteristics of the way. OpenVZ was originally released in 2005, so the design and implementation are quite mature.

Control group Cgroups

The control group is another important part of the Linux container. They implement resource accounting and constraints. They provide a lot of very useful metrics, but they also help ensure that each container gets its fair memory, CPU, disk share

I/O, and, more importantly, a single container cannot use one of these resources to paralyse the system.

Therefore, although they do not act as a process to prevent a container from accessing or affecting data and another container, they are essential to withstand some of the denial of service attacks. They are on multi-tenant platforms, like public and private

PAAs is especially important to ensure consistent uptime (and performance), even when some applications start to misbehave.

The control group has been around for some time, as well: The code started in 2006 and merged in the kernel 2.6.24.

Docker Daemon Attack surface

Running the container (and the application) with Docker means running the Docker daemon. This daemon currently requires root permissions, so you should be aware of some important details.

First, only trusted users should be able to control your Docker daemon. This is directly caused by some powerful Docker functionality. Specifically, Docker allows you to share the directory between the Docker body and the object container;

Allows you to do this without restricting access to the container. This means that you can start a container where the/host directory will be on your host/directory, and the container will be able to change your host file system without any restrictions. This

It sounds crazy? Well, you know, all virtualization systems allow file system resource sharing to behave the same way. Nothing can stop you from sharing your root file system from a virtual machine (even your root block device

）。

This has strong security implications: for example, if you are providing a container-based tool Docker from a Web server through the API, you should be more careful than you would normally use parameter checking to ensure that a malicious user is not able to pass a finely crafted parameter

Create any container from Docker.

For this reason, the rest API endpoint (the DOCKERCLI used to communicate with the Docker daemon) changes Docker0.5.2, and now uses a UNIX socket instead of a 127.0.0.1 TCP socket (after

Users are prone to cross-site scripting attacks if you happen to run Docker directly on your local computer, outside of a VM. You can then use the traditional UNIX permissions check to restrict access to the control sockets.

You can also pass exposure to the HTTP REST API if you explicitly decide to wait. But if you do, aware of the above security implications, you should make sure that it will arrive only from a trusted network or VPN, or protected as

SSL certificate with secure channel and client. You can also guarantee them HTTPS and certificates.

The latest improvements in the Linux namespace will soon allow the container to run full functionality without root privileges, thanks to the new user space. This is covered here in detail. In addition, this will solve the problem between the shared host and the customer.

File system issues because user namespaces allow users within the container (including the root user) to be mapped to other users on the host system.

Therefore, the ultimate goal is Docker to implement two additional security improvements:
Map the root user of the container to the non-root user of the Docker host to reduce the effect of container-to-host privilege elevation;
? Allows the Docker daemon to run without root privileges, and the delegate operation requires these privileges as well as the audited sub-processes, each with its own (very limited) scope of application: Virtual network settings, file System management, and so on.

Finally, if you are running Docker on a server, it is recommended that you run dedicated Docker on the server and control all other services that are moved within the container through Docker. Of course, it's good to have your favorite management tool (available

At least SSH server), as well as the existing monitoring/monitoring process (e.g., NRPE,COLLECTD, etc.).

Linux kernel capability capabilities

By default, Docker starts the container with a very limited set of features. What does that mean?

function Open Binary "root/non-root" dichotomy into fine-grained access control system. Processes (such as Web servers) that simply need to bind less than 1024 of the ports do not run as root: they can be granted

Net_bind_service ability to replace. And there are many other features, almost everywhere, that usually require the specific domain of root authority.

This means a lot of security for Docker; let's see why!

A typical server (bare metal or virtual machine) needs to run a bunch of processes as root. These typically include SSH,CRON,SYSLOGD; hardware management tools (such as load modules), network configuration tools (such as handling DHCP,WPA or VPNs)

, and so on. Containers are very different because almost all of these tasks are handled by the infrastructure around the container:
? SSH access is typically managed by a single server running by the Docker host;
? cron, when necessary, should run as a user process, dedicated, specifically for the dispatch service that needs it, rather than as a platform-based device application;
The log management layer is also usually handed over to Docker, or by third party services such as loggly or splunk;
? Hardware management is irrelevant, which means you never need to run UDEVD or equivalent daemons in a container;
? Network management occurs outside the container, performing as much separation of concerns as possible, which means that the container should not need to execute ifconfig,route, or IP commands (except when a container is designed for like a router or firewall, of course

）。

This means that in most cases, the container will not be in all the "real" root privileges required. Therefore, the container can run with a reduced capability set, which means that "root" has much less than the true "root" within a container.

Right. For example, it is possible to:
? Reject All "load" operations;
Deny access to the original socket (prevents packet spoofing);
Deny access to certain file system operations, such as creating a new device node, changing the owner of a file, or changing attributes (including immutable flags);
? reject module loading;
? and so on.

This means that even if the intruder manages to upgrade to the root container, it will be very difficult to do serious damage or upgrade to the host.

This will not affect conventional web applications; But malicious users will find that Arsenal are significantly down in their disposal! By default, Docker drops all features except those that need to be whitelisted, not blacklisted. You can

See a complete list of online Help features available in Linux.

Of course, you can always enable additional features if you really need them (for example, if you want to use the fuse-based file system), but by default, the Docker container uses the default core capabilities, only the white name

Single.

Other kernel security features

Capabilities capability is one of the many security features provided by the modern Linux kernel. Alternatively, you can use Docker with existing, well-known systems such as Tomoyo,apparmor,selinux,grsec.

While Docker currently only allows functionality, it does not interfere with other systems. This means that there are many different ways to harden the Docker host. Here are some examples.
? You can run the GRSEC and pax cores. This will add a lot of security checks, both at compile time and at run time, and it will also defeat many vulnerabilities, thanks to the technology like address randomization. It does not require Docker-specific configuration,

These safety features are available in a fully-system, stand-alone container.
? If your release comes with a Docker container security model template, you can use them out of the box. For example, launch a template with apparmor work and Red Hat's own SELinux policy Docker. These templates mention

Provides an additional safety net (even if it greatly overlaps the ability to use).
? You can use your favorite access control mechanism to define your own policies.

Just as there are many third-party tools to enhance Docker containers such as special network topologies or shared file systems, you can expect to see tools that harden existing Docker containers without compromising the core of Docker.

Conclusion

Docker containers, by default, are fairly secure, especially if you take care of your running process containers for non-privileged users (that is, non-root).

You can add additional layers of security by enabling AppArmor, Selinux,grsec, or your favorite hardening solution.

Last but not least, if you see in other containerized systems, interesting security features, you will be able to implement them, as well as use Docker, because everything is provided by the kernel anyway.

For more information, especially compared to virtual machines and other container systems, see the original blog post: http://blog.docker.com/2013/08/containers-docker-how-secure-are-they/.

Docker Security-official documents [translate]