IMCAFS

Home

17 suggestions for docker security deployment

Posted by santillano at 2020-02-25
all

[editor's note] the author of this paper gives his own suggestions from docker image, network namespace, log and audit, daemons privilege, SELinux, binary suid / guid, device control group, service and application, Linux kernel, user namespace, libseccomp, etc., which can be read first.

At present, the growing cloud computing market has a strong demand for virtualization technology. Unfortunately, most virtualization solutions are not flexible enough to meet R & D requirements, and the potential cost of using full virtualization solutions has become a burden restricting infrastructure scalability.

Docker enables developers and operation and maintenance personnel to seamlessly deploy containers to run applications and services required by business, thus reducing such overhead. However, because docker and the host system use the same kernel, improper configuration of containers will cause major security risks.

Each of the following lists provides recommendations for improving the safety of the relevant container environment. It should be noted that these solutions only apply to docker containers deployed on Linux hosts, and use the latest docker Version (1.4.0, commit 4595d4f, date 11 / 12 / 14).

The following sections refer to the articles of J é R ô me petazzoni [1] and Daniel J Walsh [2]. This article aims to supplement their suggestions and explain how to implement them in docker.

Note: most of the recommended command-line options can be saved and used in a similar way in the dockerfile to achieve automatic image building. (Note: the original 17 suggestions are presented in tabular form. Due to the editor, they will be expressed in tabular form here.)

1. Docker image

Docker 1.3 began to support the use of digital signature [3] to verify the source and integrity of the official warehouse image. This feature is still under development, so docker only warns the image but does not prevent it from actually running. In addition, this does not apply to unofficial images.

In general, we want to make sure that we only get the image from the trusted library, and do not use the -- secure - Registry = [] parameter.

--insecure-registry=[]

2. Network namespace [4]

By default, the docker daemons expose that the rest API used to control containers can only be accessed locally through UNIX domain socket.

Running docker on a TCP port (for example, using the - H option to force the binding address when starting the docker daemons) will allow anyone who can access the port to obtain access to the container, even if the local user belongs to the docker group in some cases, it is possible to obtain the root permission of the host. [5]

When the daemons are allowed to be accessed through TCP, ensure that the communication uses SSL encryption [6] and permission control to effectively prevent unauthorized users from interacting with them.

The iptables rule of kernel firewall can be enabled on docker's standard network bridging interface docker0 to strengthen these controls.

docker0

For example, the following iptables filter [7] can be used to restrict the source IP address range of the docker container from communicating with the outside world. iptables -t filter -A FORWARD -s <source_ip_range> -j REJECT --reject-with icmp-admin-prohibited

3. Log and audit

Collect and archive docker related security logs to achieve audit and monitoring purposes. Log files can be accessed outside the container using the following command on the host [8]:

Use docker built-in commands:

Log files can also be exported to a compressed package for persistent storage:

4. SELinux or AppArmor

Through the security policy of access control, Linux kernel security modules, such as SELinux and AppArmor, can be configured to implement mandatory access control (MAC) to restrict the process in a limited set of system resources or permissions.

If SELinux has been previously installed and configured, you can use setenforce 1 in the container to enable it. SELinux function of docker daemons is disabled by default. You need to use -- SELinux enabled to enable it.

--selinux-enabled

The label restriction of the container can be configured by using the new policy - Security opt to load SELinux or AppArmor, which is introduced in docker version 1.3 [9].

—-security-opt

For example:

5. Daemons privileges

Do not use the -- privileged command line option. Otherwise, the container will be allowed to access all devices on the host. In addition, providing a specific LSM (such as SELinux or AppArmor) configuration for the container will give it the same access rights as the process running on the host.

--privileged

Avoid using -- privileged helps reduce attack surface and possible host threats. However, this does not mean that you do not need root permission to run daemons, which is still required in the latest version.

--privileged

Permissions to start daemons and containers can only be granted to trusted users.

You can use the - U option to weaken access within the container. For example:

Any user part of the docker group may eventually get the root cause from the host in the container.

6. cgroups[10]

To prevent a denial of service (DOS) attack by exhausting system resources, some resource restrictions can be enabled using specific command line parameters.

CPU usage:

Memory usage:

Storage usage:

Disk I / O: currently docker does not support it. The blockio * feature exposed through SYSTEMd can be used to control disk usage quotas in supported operating systems.

7. Binary suid / guid

The suid and guid programs are very dangerous when they are attacked and cause arbitrary code execution, such as a buffer overflow, because they will run in the context of the process file owner or group.

If possible, use specific command-line arguments to reduce the ability to give containers and prevent suid and sgid from taking effect.

As an alternative, consider using the nosuid attribute to remove the suid capability when mounting the file system.

nosuid

Finally, delete the suid and guid programs that are not needed in the system. Such programs can be found by running the following commands in Linux system:

You can then remove the suid and guid file permissions using a [11] command similar to the following:

8. Device control group (/ dev / *)

If necessary, use the built-in -- device option (- V parameter is not used with -- privileged). This feature was introduced in version 1.2 [12].

--device

For example (using a sound card):

9. Services and Applications

If the docker container is likely to be intruded, in order to reduce the possibility of lateral movement, consider isolating sensitive services (such as running SSH services on the host or virtual machine).

In addition, do not run untrusted applications within the container with root privileges.

10. Mount point

When using a native container library, such as libcontainer, docker automatically handles this.

However, when using the LXC container library, it is better to mount sensitive mount points manually with read-only permission, including:

Mount permissions should be removed later to prevent re mounting.

11. Linux kernel

Use the update tools provided by the system (such as apt get, yum, etc.) to ensure that the kernel is up-to-date. Older kernels are more dangerous than open ones.

Use grsec or Pax to strengthen the kernel, for example, to provide higher security against memory corruption vulnerabilities.

12. User namespace

Docker does not support user namespaces, but it is a feature of [13] that is currently being developed. Now, the LxC driver supports uid mapping, but the native libcontainer library does not.

This feature allows the docker daemons to run on the host as unprivileged users, but inside the container it looks like it is running as root.

13. Libseccomp (and seccomp BPF extension)

The libseccomp library allows whitelist based methods to limit the use of system callers in the Linux kernel. It is best to disable the system callers in the attacked container that are not important for system operation to prevent them from being abused or misused.

This feature is currently under development (it exists in the LxC driver, but not in the default libcontainer). Use LxC driver [14] to restart docker program:

Instructions on how to generate seccomp configuration are all in the "contrib" [15] folder of GitHub warehouse. After that, you can use the following command to create an LxC based docker container:

14. Ability [7]

Minimize Linux capabilities. Docker's default capabilities include chown, dac_override, Fowler, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, setfcap, and audit_write '.

chown dac_override fowner kill、 setuid、 net_bind_service、 sys_chroot、 setfcap、和

When you start a container on the command line, you can control it through -- CAP add = [] or -- cap drop = [].

--cap-add=[] --cap-drop=[]

For example:

This function is introduced in docker version 1.2 [16].

15. Multi tenant environment

Due to the shared nature of docker container kernel, responsibility separation cannot be realized safely in multi tenant environment. It is recommended to run the container on a host that has no other purpose and is not used for sensitive operations. You can consider migrating all services to the container city controlled by docker.

If possible, set the daemons to use -- ICC = false, and specify - link when docker runs as needed, or expose a port of the container through -- export = port, without publishing on the host.

--icc=false —-export=port

Map groups of trusted containers to different machines [17].

16. Full virtualization

Use a fully virtualized solution to accommodate dockers, such as KVM. If a kernel vulnerability is found in the container, this will prevent it from expanding from the container to the host.

As shown in docker in docker tool [18], docker images can be nested to provide the KVM virtual layer.

17. Safety audit

Perform regular security checks on your host system and containers to identify misconfigurations or vulnerabilities that may cause the system to be compromised.

References: [1] docker, Linux containers (LxC), and security (August, 2014). J é R ô me petazzoni. [presentation slides] [2] docker and SELinux (July, 2014). Daniel Walsh [Video] [3] docker 1.3: signed images, process injection, security options, Mac shared directions (October, 2014). Scott Johnston [4] exploring LXC Networking (November, 2013) Milos Gajdos. PaaS under the hood, episode 1: kernel namespaces (November, 2012). Jérôme Petazzoni. Exploring networking in Linux containers (January, 2014). Milos Gajdos. [presentation slides] [5] How to grant rights to users to use Docker in Fedora (October 2014). Daniel Walsh [6] Running Docker with https. [Docker documentation] [7] security suggestions when running malicious code, Google Groups (August, 2013). Jérôme Petazzoni [8] Monitoring Images and Containers. [Red Hat documentation] [9] Docker 1.3: Signed Images, Process Injection, Security Options, Mac shared directories (October, 2014). Scott Johnston [10] Resource management in Docker (September, 2014). Marek Goldmann. Gathering LXC and Docker Containers Metrics (October, 2013). Jérôme Petazzoni. [11] Removing SUID and SGID flags off binaries (August, 2008). Eric Thern. [12] Announcing Docker 1.2.0 (August, 2014). Victor Vieux. [13] Having non-root privileges on the host and root inside the container #2918 (November, 2013). [GitHub issue] Support for user namespaces #4572 (March 2014). [GitHub issue] Proposal: Support for user namespaces #7906 (September, 2014). [GitHub issue] Issue 8447: syscall, os/exec: Support for User Namespaces (July, 2014) [Google Code issue] [14] Docker 0.9: Introducing Execution Drivers and libcontainer (March, 2014). Solomon Hykes [15] A simple helper script to help people build seccomp profiles for Docker/LXC (November 2013). Martijn van Oosterhout. https://github.com/docker/dock ... ample [16] Announcing Docker 1.2.0 (August, 2014). Victor Vieux. [17] Docker Container Breakout Proof-of-Concept Exploit (June, 2014). James Turnbull [18] docker2docker GitHub repository. Jérôme Petazzoni.

Original: docker secure deployment guidelines

================================================================ translator introduction to Wu Jinsheng, a postgraduate of Dalian University of technology, works in the technology center of Shanghai Jinqiao Information Co., Ltd. At present, he is responsible for the research and application of cloud computing, virtualization, big data and information visualization. I hope to make a modest contribution to docker's path by translating technical articles into the dockone community.