AonCyberLabs/Docker-Secure-Deployment-Guidelines

Docker 1.3 now supports cryptographic signatures ^[3] to ascertain the origin and integrity of official repository images. This feature is however still a work in progress as Docker will issue a warning but not prevent the image from actually running. Furthermore, it does not apply to non-official images.

In general, ensure that images are only retrieved from trusted repositories and that the --insecure-registry=[] command line option is never used.

By default, the Docker REST API used to control containers exposed via the system Docker daemon is only accessible locally via a Unix domain socket.

Running Docker on a TCP port (i.e. forcing the bind address using the -H option when launching the Docker daemon) will allow anyone with access to that port to gain access to the container, potentially gaining root access on the host as well in some scenarios where the local user belongs to the docker group ^[5].

When allowing access to the daemon over TCP, ensure that communications are adequately encrypted using SSL ^[6] and access controls effectively prevent unauthorised parties from interacting with it.

Kernel firewall iptables rules can be applied to docker0, the standard network bridge interface for Docker, to enforce those controls.

For instance, the source IP range of a Docker container can be restricted from talking with the outside world using the following iptables filter ^[7]. iptables -t filter -A FORWARD -s <source_ip_range> -j REJECT --reject-with icmp-admin-prohibited

Collect and archive security logs relating to Docker for auditing and monitoring purposes.

Accessing log files outside of the container, from the host ^[8], can be performed using the following command:
docker run -v /dev/log:/dev/log <container_name> /bin/sh

Using the Docker command built-in:
docker logs ... (-f to follow log output)

Log files can also be exported for persistent storage into a tarball using:
docker export ...

Linux kernel security modules such as Security-Enhanced Linux (SELinux) and AppArmor can be configured, via access control security policies, to implement mandatory access controls (MAC) confining processes to a limited set of system resources or privileges.

SELinux can be enabled in the container using setenforce 1, if it was previously installed and configured. The SELinux support for the Docker daemon is disabled by default and needs to be enabled using --selinux-enabled.

Introduced in Docker version 1.3 ^[9], label confinement for the container can be configured using the newly added --security-opt argument to load SELinux or AppArmor policies, as shown in the Docker run reference excerpt below.

--security-opt="label:user:USER" : Set the label user for the container
--security-opt="label:role:ROLE" : Set the label role for the container
--security-opt="label:type:TYPE" : Set the label type for the container
--security-opt="label:level:LEVEL" : Set the label level for the container
--security-opt="apparmor:PROFILE" : Set the apparmor profile to be applied to the container

Example:
docker run --security-opt=label:level:s0:c100,c200 -i -t centos bash

Do not use the --privileged command line option. This would otherwise allow the container to access all devices on the host and would in addition provide the container with specific a LSM (i.e SELinux or AppArmor) configuration that would give it the same level of access as processes running on the host.

Avoiding the use of --privileged helps reduce the attack surface and potential of host compromise. This however does not mean that the daemon will run without root privileges which is still currently required in the latest release.

The ability to launch the daemon and containers should only be given to trusted user.

Minimize privileges enforced inside the container by leveraging the -u option.
Example:
docker run -u <username> -it <container_name> /bin/bash

Any user part of the docker group could eventually get root on the host from the container

In order to prevent Denial of Service (DoS) attacks via system resource exhaustion, a number of resource restrictions can be applied using specific command line arguments.

CPU usage:
docker run -it --rm --cpuset=0,1 -c 2 ...

Memory usage:
docker run -it --rm -m 128m ...

Storage usage:
docker -d --storage-opt dm.basesize=5G

Disk I/O:
Currently not supported by Docker. BlockIO* properties exposed via systemd can be leveraged to control disk usage quotas on supported operating systems.

SUID and GUID binaries can prove dangerous when vulnerable to attacks leading to arbitrary code execution (e.g. buffer overflows), as they will be running under the context of the process’s file owner or group.

When possible, prohibit SUID and SGID from taking effect by reducing the capabilities given to containers using specific command line arguments.
docker run -it --rm --cap-drop SETUID --cap-drop SETGID ...

Alternatively, consider removing SUID capabilities from the system by mounting filesystem with the nosuid attribute.

One last option could be to remove unwanted SUID and GUID binaries from the system altogether. These types of binaries can be found on a Linux system by running the following commands:
find / -perm -4000 -exec ls -l {} \; 2>/dev/null
find / -perm -2000 -exec ls -l {} \; 2>/dev/null

The SUID and GUID file permissions can then be removed using commands similar to the following ^[11]:
sudo chmod u-s filename sudo chmod -R g-s directory

If required, mount devices using the built-in --device option (do not use -v with the --privileged argument).

Granular permissions can be assigned to each device using a third set of options :rwm to override read, write, and mknod permissions respectively (default includes all permissions).

Example (for using sound card with read-only permission):
docker run --device=/dev/snd:/dev/snd:r ...

This feature was introduced in version 1.2 ^[12].

To reduce the potential for lateral movement if a Docker container was to be compromised, consider isolating sensitive services (e.g. run SSH service on bastion host or in a VM).

Furthermore, do not run untrusted applications with root privileges within containers.

This is handled automatically by Docker when using the native container library (i.e. libcontainer).

However, when using the LXC container library, sensitive mount points should ideally be manually mounted with read-only permissions, including:

• /sys
  
• /proc/sys
  
• /proc/sysrq-trigger
  
• /proc/irq
  
• /proc/bus

Ensure kernel is up-to-date using update utility provided by the system (e.g. apt-get, yum, etc). Out-dated kernels are more likely to be vulnerable to publicly disclosed vulnerabilities.

Use strengthened a kernel with GRSEC or PAX, that for example provide increased security against memory corruption bugs.

Docker does not support user namespaces but is a feature currently under development ^[13]. UID mapping is currently supported by the LXC driver but not in the native libcontainer library.

This feature would allow the Docker daemon to run as an unprivileged user on the host but appear as running as root within containers. While using the LXC driver this can by using the -lxc-conf option, as shown in the example Docker run command below.

The specified arguments in the above command will instruct Docker to map UIDs and GIDs 100000 through 65536 on the host to UIDs and GIDs 0 through 65536 to a specific user account, defined at system level on the host in a configuration similar to: ^[14]

The libseccomp library allows restricting the use of Linux kernel’s syscall procedures based on a white-list approach. Syscall procedures not vital to system operation should ideally be disabled to prevent abuse or misuse within a compromised container.

This feature is currently a work in progress (available in LXC driver, not in libcontainer which is now default).

To restart the Docker daemon to use the LXC driver use ^[15]:
docker -d -e lxc

Instructions on how to generate a seccomp configuration are on the Docker GitHub repository within the 'contrib' ^[16] folder. This can later be used to create a LXC based Docker container using the following command:
docker run --lxc-conf="lxc.seccomp=$file" <rest of arguments>

Drop linux capabilities to a minimum whenever possible. Docker default capabilities include: chown, dac_override, fowner, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, setfcap, and audit_write.

Can be controlled when launching a container from command line with --cap-add=[] or --cap-drop=[].

Example:
docker run --cap-drop setuid --cap-drop setgid -ti <container_name> /bin/sh

This feature was introduced in Docker version 1.2 ^[17]

Due to the shared nature of Docker containers’ kernel, separation of duty in multi-tenancy environments cannot be achieved securely. It is recommended that containers be run on hosts that have no other purposes and are not used for sensitive operations. Consider moving all services into containers controlled by Docker.

When possible, keep inter-container communications to a minimum by setting the Docker daemon to use --icc=false and specify -link with docker run when necessary, or --export=port to expose a port from the container without publishing it on the host.

Map groups of mutually-trusted containers to separate machines ^[18].

Use a full virtualisation solution to contain Docker, such as KVM. This will prevent escalation from the container to the host if a kernel vulnerability is exploited inside the Docker image.

Docker images can be nested to provide this KVM virtualisation layer as shown in the Docker-in-Docker utility ^[19].

Perform regular security audits of your host system and containers to identify mis-configuration or vulnerabilities that could expose your system to compromise.