{"id":13416618,"url":"https://github.com/AonCyberLabs/Docker-Secure-Deployment-Guidelines","last_synced_at":"2025-03-15T00:31:12.359Z","repository":{"id":24421257,"uuid":"27822309","full_name":"AonCyberLabs/Docker-Secure-Deployment-Guidelines","owner":"AonCyberLabs","description":"Deployment checklist for securely deploying Docker","archived":false,"fork":false,"pushed_at":"2016-11-01T11:03:00.000Z","size":28,"stargazers_count":598,"open_issues_count":1,"forks_count":84,"subscribers_count":64,"default_branch":"master","last_synced_at":"2024-04-13T18:31:30.719Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/AonCyberLabs.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2014-12-10T13:59:47.000Z","updated_at":"2024-04-05T14:10:12.000Z","dependencies_parsed_at":"2022-08-06T01:15:48.103Z","dependency_job_id":null,"html_url":"https://github.com/AonCyberLabs/Docker-Secure-Deployment-Guidelines","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AonCyberLabs%2FDocker-Secure-Deployment-Guidelines","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AonCyberLabs%2FDocker-Secure-Deployment-Guidelines/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AonCyberLabs%2FDocker-Secure-Deployment-Guidelines/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AonCyberLabs%2FDocker-Secure-Deployment-Guidelines/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/AonCyberLabs","download_url":"https://codeload.github.com/AonCyberLabs/Docker-Secure-Deployment-Guidelines/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243667737,"owners_count":20328032,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-07-30T21:01:02.385Z","updated_at":"2025-03-15T00:31:12.018Z","avatar_url":"https://github.com/AonCyberLabs.png","language":null,"readme":"\u003chtml\u003e\n\n\u003chead\u003e\n\u003ch3\u003eDocker Secure Deployment Guidelines\u003c/h3\u003e\n\u003c/head\u003e\n\n\u003cbody\u003e\n\n\u003cp align=\"justify\"\u003e\nWithin today’s growing cloud-based IT market, there is a strong demand for virtualisation technologies. Unfortunately most virtualisation solutions are not flexible enough to meet developer requirements and the overhead implied by the use of full virtualisation solutions becomes a burden on the scalability of the infrastructure. \n\u003cbr\u003e\u003cbr\u003e\nDocker reduces that overhead by allowing developers and system administrators to seamlessly deploy containers for applications and services required for business operations. However, because Docker leverages the same kernel as the host system to reduce the need for resources, containers can be exposed to significant security risks if not adequately configured.\n\u003cbr\u003e\u003cbr\u003e\nThe following itemised list suggests hardening actions that can be undertaken to improve the security posture of the containers within their respective environment. It should be noted that proposed solutions only apply to deployment of Linux Docker containers on Linux-based hosts, using the most recent release of Docker at the time of this writing (1.4.0, commit \u003ccode\u003e4595d4f\u003c/code\u003e, dating 11/12/14).\n\u003cbr\u003e\u003cbr\u003e\nPart of the content below is based on publications from Jérôme Petazzoni\u003csup\u003e [1]\u003c/sup\u003e and Daniel J Walsh\u003csup\u003e [2]\u003c/sup\u003e. This document aims at adding on to their recommendations and how they can specifically be implemented within Docker.\n\u003cbr\u003e\u003cbr\u003e\n\u003cem\u003eNote\u003c/em\u003e: Most of suggested command line options can be stored and used in a similar manner inside a Dockerfile for automated image building.\n\u003c/p\u003e\n\n\u003ctable tyle=\"width:100%\"\u003e\n  \u003ctr\u003e\n    \u003cth\u003eItem\u003c/th\u003e\n    \u003cth\u003eDeployment\u003c/th\u003e \n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003eDocker Images\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eDocker 1.3 now supports cryptographic signatures\u003csup\u003e [3]\u003c/sup\u003e 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.\n    \u003cbr\u003e\n    \u003cbr\u003e\n    In general, ensure that images are only retrieved from trusted repositories and that the \u003ccode\u003e--insecure-registry=[]\u003c/code\u003e command line option is never used.\u003c/td\u003e \n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003eNetwork Namespaces\u003csup\u003e [4]\u003c/sup\u003e\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eBy default, the Docker REST API used to control containers exposed via the system Docker daemon is only accessible locally via a Unix domain socket.\n    \u003cbr\u003e\n    \u003cbr\u003e\n    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\u003csup\u003e [5]\u003c/sup\u003e. \n    \u003cbr\u003e\n    \u003cbr\u003e\n    When allowing access to the daemon over TCP, ensure that communications are adequately encrypted using SSL\u003csup\u003e [6]\u003c/sup\u003e and access controls effectively prevent unauthorised parties from interacting with it.\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Kernel firewall iptables rules can be applied to \u003ccode\u003edocker0\u003c/code\u003e, the standard network bridge interface for Docker, to enforce those controls.\n    \u003cbr\u003e\n    \u003cbr\u003e\n    For instance, the source IP range of a Docker container can be restricted from talking with the outside world using the following iptables filter\u003csup\u003e [7]\u003c/sup\u003e.\n    \u003ccode\u003eiptables -t filter -A FORWARD -s \u0026lt;source_ip_range\u0026gt; -j REJECT --reject-with icmp-admin-prohibited\u003ccode\u003e\u003c/p\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003eLogging \u0026 Auditing\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eCollect and archive security logs relating to Docker for auditing and monitoring purposes.\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Accessing log files outside of the container, from the host\u003csup\u003e [8]\u003c/sup\u003e, can be performed using the following command:\u003cbr\u003e\n    \u003ccode\u003edocker run -v /dev/log:/dev/log \u0026lt;container_name\u0026gt; /bin/sh\u003c/code\u003e\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Using the Docker command built-in:\u003cbr\u003e\n    \u003ccode\u003edocker logs ...\u003c/code\u003e\n    (-f to follow log output)\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Log files can also be exported for persistent storage into a tarball using:\u003cbr\u003e\n    \u003ccode\u003edocker export ...\u003c/code\u003e\u003c/p\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003eSELinux or AppArmor\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eLinux 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.\n    \u003cbr\u003e\n    \u003cbr\u003e  \n    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 \u003ccode\u003e--selinux-enabled\u003c/code\u003e.\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Introduced in Docker version 1.3\u003csup\u003e [9]\u003c/sup\u003e, label confinement for the container can be configured using the newly added \u003ccode\u003e--security-opt\u003c/code\u003e argument to load SELinux or AppArmor policies, as shown in the Docker \u003ccode\u003erun\u003c/code\u003e reference excerpt below.\n    \u003cbr\u003e\n    \u003cbr\u003e\n    \u003ccode\u003e--security-opt=\"label:user:USER\"\u003c/code\u003e   : Set the label user for the container\u003cbr\u003e\n    \u003ccode\u003e--security-opt=\"label:role:ROLE\"\u003c/code\u003e   : Set the label role for the container\u003cbr\u003e\n    \u003ccode\u003e--security-opt=\"label:type:TYPE\"\u003c/code\u003e   : Set the label type for the container\u003cbr\u003e\n    \u003ccode\u003e--security-opt=\"label:level:LEVEL\"\u003c/code\u003e : Set the label level for the container\u003cbr\u003e\n    \u003ccode\u003e--security-opt=\"apparmor:PROFILE\"\u003c/code\u003e  : Set the apparmor profile to be applied to the container\n    \u003cbr\u003e\n    \u003cbr\u003e\n    \u003cem\u003eExample:\u003c/em\u003e\u003cbr\u003e\n    \u003ccode\u003edocker run --security-opt=label:level:s0:c100,c200 -i -t centos bash\u003c/code\u003e\u003c/p\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003eDaemon Privileges\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eDo not use the \u003ccode\u003e--privileged\u003c/code\u003e 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.\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Avoiding the use of \u003ccode\u003e--privileged\u003c/code\u003e 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. \n    \u003cbr\u003e\n    \u003cbr\u003e\n    The ability to launch the daemon and containers should only be given to trusted user.\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Minimize privileges enforced inside the container by leveraging the -u option.\u003cbr\u003e\n    \u003cem\u003eExample:\u003c/em\u003e\u003cbr\u003e\n    \u003ccode\u003edocker run -u \u0026lt;username\u0026gt; -it \u0026lt;container_name\u0026gt; /bin/bash\u003c/code\u003e \n    \u003cbr\u003e\u003cbr\u003e\n    Any user part of the docker group could eventually get root on the host from the container\u003c/p\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003ecgroups\u003csup\u003e [10]\u003c/sup\u003e\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eIn 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.\n    \u003cbr\u003e\n    \u003cbr\u003e\n    CPU usage:\u003cbr\u003e\n    \u003ccode\u003edocker run -it --rm --cpuset=0,1 -c 2 ...\u003c/code\u003e\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Memory usage:\u003cbr\u003e\n    \u003ccode\u003edocker run -it --rm -m 128m ...\u003c/code\u003e\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Storage usage:\u003cbr\u003e\n    \u003ccode\u003edocker -d --storage-opt dm.basesize=5G\u003c/code\u003e\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Disk I/O:\u003cbr\u003e\n    Currently not supported by Docker. BlockIO* properties exposed via systemd can be leveraged to control disk usage quotas on supported operating systems.\u003c/p\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003eSUID/GUID binaries\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eSUID 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. \n    \u003cbr\u003e\n\t\u003cbr\u003e\n    When possible, prohibit SUID and SGID from taking effect by reducing the capabilities given to containers using specific command line arguments.\u003cbr\u003e\n    \u003ccode\u003edocker run -it --rm --cap-drop SETUID --cap-drop SETGID ...\u003c/code\u003e\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Alternatively, consider removing SUID capabilities from the system by mounting filesystem with the \u003ccode\u003enosuid\u003c/code\u003e attribute.\n    \u003cbr\u003e\n    \u003cbr\u003e    \n    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:\u003cbr\u003e\n    \u003ccode\u003efind / -perm -4000 -exec ls -l {} \\; 2\u003e/dev/null\u003c/code\u003e\u003cbr\u003e\n    \u003ccode\u003efind / -perm -2000 -exec ls -l {} \\; 2\u003e/dev/null\u003c/code\u003e\n    \u003cbr\u003e\n    \u003cbr\u003e\n    The SUID and GUID file permissions can then be removed using commands similar to the following\u003csup\u003e [11]\u003c/sup\u003e:\u003cbr\u003e\n    \u003ccode\u003esudo chmod u-s filename\u003c/code\u003e\n    \u003ccode\u003esudo chmod -R g-s directory\u003c/code\u003e\u003c/p\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003eDevices control group (/dev/*)\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eIf required, mount devices using the built-in \u003ccode\u003e--device\u003c/code\u003e option (do not use -v with the \u003ccode\u003e--privileged\u003c/code\u003e argument). \n    \u003cbr\u003e\n    \u003cbr\u003e\n    Granular permissions can be assigned to each device using a third set of options \u003ccode\u003e:rwm\u003c/code\u003e to override \u003ccode\u003eread\u003c/code\u003e, \u003ccode\u003ewrite\u003c/code\u003e, and \u003ccode\u003emknod\u003c/code\u003e permissions respectively (default includes all permissions).\n    \u003cbr\u003e\n    \u003cbr\u003e\n    \u003cem\u003eExample (for using sound card with read-only permission):\u003c/em\u003e\u003cbr\u003e\n    \u003ccode\u003edocker run --device=/dev/snd:/dev/snd:r  ...\u003c/code\u003e\n    \u003cbr\u003e\n    \u003cbr\u003e\n    This feature was introduced in  version 1.2\u003csup\u003e [12]\u003c/sup\u003e.\u003c/p\u003e\u003c/td\u003e \n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003eServices and Applications\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eTo 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).\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Furthermore, do not run untrusted applications with root privileges within containers.\u003c/p\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003eMount Points\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eThis is handled automatically by Docker when using the native container library (i.e. libcontainer). \n    \u003cbr\u003e\n    \u003cbr\u003e\n    However, when using the LXC container library, sensitive mount points should ideally be manually mounted with read-only permissions, including:\u003cbr\u003e\n    \u003cul\u003e\n        \u003cli\u003e\u003ccode\u003e/sys\u003c/code\u003e\u003cbr\u003e\u003c/li\u003e \n        \u003cli\u003e\u003ccode\u003e/proc/sys\u003c/code\u003e\u003cbr\u003e\u003c/li\u003e\n        \u003cli\u003e\u003ccode\u003e/proc/sysrq-trigger\u003c/code\u003e\u003cbr\u003e\u003c/li\u003e \n        \u003cli\u003e\u003ccode\u003e/proc/irq\u003c/code\u003e\u003cbr\u003e\u003c/li\u003e\n        \u003cli\u003e\u003ccode\u003e/proc/bus\u003c/code\u003e\u003c/li\u003e\n    \u003c/ul\u003e\n    Mount permissions should later be removed to prevent remounting.\u003c/p\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003eLinux Kernel\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eEnsure 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.\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Use strengthened a kernel with GRSEC or PAX, that for example provide increased security against memory corruption bugs.\u003c/p\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003eUser Namespaces\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eDocker does not support user namespaces but is a feature currently under development\u003csup\u003e [13]\u003c/sup\u003e. UID mapping is currently supported by the LXC driver but not in the native libcontainer library.\n    \u003cbr\u003e\n    \u003cbr\u003e    \n    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 \u003ccode\u003e-lxc-conf\u003c/code\u003e option, as shown in the example Docker \u003ccode\u003erun\u003c/code\u003e command below.\u003c/p\u003e\n    \u003ccode\u003edocker run -lxc-conf=\"lxc.id_map = u 0 100000 65536\" -lxc-conf=\"lxc.id_map = g 0 100000 65536\" ...\u003c/code\u003e\n    \u003cbr\u003e\n    \u003cbr\u003e\n    \u003cp align=\"justify\"\u003eThe 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:\u003csup\u003e [14]\u003c/sup\u003e\u003c/p\u003e\n    \u003ccode\u003e/etc/subgid:\u003cem\u003e\u0026lt;username\u0026gt;\u003c/em\u003e:100000:65536\u003c/code\u003e\u003cbr\u003e\n    \u003ccode\u003e/etc/subuid:\u003cem\u003e\u0026lt;username\u0026gt;\u003c/em\u003e:100000:65536\u003c/code\u003e \n    \u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003elibseccomp (and seccomp-bpf extension)\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eThe 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.\n    \u003cbr\u003e\n    \u003cbr\u003e\n    This feature is currently a work in progress (available in LXC driver, not in libcontainer which is now default).\n    \u003cbr\u003e\n    \u003cbr\u003e\n    To restart the Docker daemon to use the LXC driver use\u003csup\u003e [15]\u003c/sup\u003e:\u003cbr\u003e\n    \u003ccode\u003edocker -d -e lxc\u003c/code\u003e\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Instructions on how to generate a seccomp configuration are on the Docker GitHub repository within the 'contrib'\u003csup\u003e [16]\u003c/sup\u003e folder. This can later be used to create a LXC based Docker container using the following command:\u003cbr\u003e\n    \u003ccode\u003edocker run --lxc-conf=\"lxc.seccomp=$file\" \u0026lt;rest of arguments\u0026gt;\u003c/code\u003e\u003c/p\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003e\u003ccode\u003ecapabilities(7)\u003c/code\u003e\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eDrop linux capabilities to a minimum whenever possible.\n    Docker default capabilities include: \u003ccode\u003echown\u003c/code\u003e, \u003ccode\u003edac_override\u003c/code\u003e, \u003ccode\u003efowner\u003c/code\u003e, \u003ccode\u003ekill\u003c/code\u003e, \u003ccode\u003esetgid\u003c/code\u003e, \u003ccode\u003esetuid\u003c/code\u003e, \u003ccode\u003esetpcap\u003c/code\u003e, \u003ccode\u003enet_bind_service\u003c/code\u003e, \u003ccode\u003enet_raw\u003c/code\u003e, \u003ccode\u003esys_chroot\u003c/code\u003e, \u003ccode\u003emknod\u003c/code\u003e, \u003ccode\u003esetfcap\u003c/code\u003e, and \u003ccode\u003eaudit_write\u003c/code\u003e.\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Can be controlled when launching a container from command line with \u003ccode\u003e--cap-add=[]\u003c/code\u003e or \u003ccode\u003e--cap-drop=[]\u003c/code\u003e. \n    \u003cbr\u003e\n    \u003cbr\u003e\n    \u003cem\u003eExample:\u003c/em\u003e\u003cbr\u003e\n    \u003ccode\u003edocker run --cap-drop setuid --cap-drop setgid -ti \u0026lt;container_name\u0026gt; /bin/sh\u003c/code\u003e\n    \u003cbr\u003e\n    \u003cbr\u003e\n    This feature was introduced in Docker version 1.2\u003csup\u003e [17]\u003c/sup\u003e\u003c/p\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003eMulti-tenancy Environments\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eDue 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.\n    \u003cbr\u003e\n    \u003cbr\u003e \n    When possible, keep inter-container communications to a minimum by setting the Docker daemon to use \u003ccode\u003e--icc=false\u003c/code\u003e and specify -link with docker run when necessary, or \u003ccode\u003e--export=port\u003c/code\u003e to expose a port from the container without publishing it on the host.\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Map groups of mutually-trusted containers to separate machines\u003csup\u003e [18]\u003c/sup\u003e.\u003c/p\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003eFull Virtualisation\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003eUse 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.\n    \u003cbr\u003e\n    \u003cbr\u003e\n    Docker images can be nested to provide this KVM virtualisation layer as shown in the Docker-in-Docker utility\u003csup\u003e [19]\u003c/sup\u003e.\u003c/p\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd valign=\"top\"\u003eSecurity Audits\u003c/td\u003e\n    \u003ctd\u003e\u003cp align=\"justify\"\u003ePerform regular security audits of your host system and containers to identify mis-configuration or vulnerabilities that could expose your system to compromise.\u003c/p\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n\u003c/table\u003e\n\n\u003ch2\u003eReferences\u003c/h2\u003e\n[1] \u003cem\u003eDocker, Linux Containers (LXC), and security\u003c/em\u003e (August, 2014). Jérôme Petazzoni. [presentation slides]\nhttp://www.slideshare.net/jpetazzo/docker-linux-containers-lxc-and-security\n\u003cbr\u003e[2] \u003cem\u003eDocker and SELinux\u003c/em\u003e (July, 2014). Daniel Walsh [video]\nhttps://www.youtube.com/watch?v=zWGFqMuEHdw\n\u003cbr\u003e[3] \u003cem\u003eDocker 1.3: Signed Images, Process Injection, Security Options, Mac shared directories\u003c/em\u003e (October, 2014). Scott Johnston\nhttp://blog.docker.com/2014/10/docker-1-3-signed-images-process-injection-security-options-mac-shared-directories/\n\u003cbr\u003e[4] \u003cem\u003eExploring LXC Networking\u003c/em\u003e (November, 2013). Milos Gajdos.\nhttp://containerops.org/2013/11/19/lxc-networking/\n\u003cbr\u003e    \u003cem\u003ePaaS under the hood, episode 1: kernel namespaces\u003c/em\u003e (November, 2012). Jérôme Petazzoni.\nhttp://blog.dotcloud.com/under-the-hood-linux-kernels-on-dotcloud-part\n\u003cbr\u003e    \u003cem\u003eExploring networking in Linux containers\u003c/em\u003e (January, 2014). Milos Gajdos. [presentation slides]\nhttps://speakerdeck.com/gyre007/exploring-networking-in-linux-containers\n\u003cbr\u003e[5] \u003cem\u003eHow to grant rights to users to use Docker in Fedora\u003c/em\u003e (October 2014). Daniel Walsh\nhttp://opensource.com/business/14/10/docker-user-rights-fedora \n\u003cbr\u003e[6] \u003cem\u003eRunning Docker with https.\u003c/em\u003e [Docker documentation]\nhttps://docs.docker.com/articles/https/\n\u003cbr\u003e[7] \u003cem\u003esecurity suggestions when running malicious code\u003c/em\u003e, Google Groups (August, 2013). Jérôme Petazzoni \nhttps://groups.google.com/forum/#!msg/docker-user/uuiQ3Nk3uSY/SuFpdO6BPmYJ\n\u003cbr\u003e[8] \u003cem\u003eMonitoring Images and Containers.\u003c/em\u003e [Red Hat documentation]\nhttps://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Resource_Management_and_Linux_Containers_Guide/sec-Monitoring_Images.html\n\u003cbr\u003e[9] \u003cem\u003eDocker 1.3: Signed Images, Process Injection, Security Options, Mac shared directories\u003c/em\u003e (October, 2014). Scott Johnston\nhttp://blog.docker.com/2014/10/docker-1-3-signed-images-process-injection-security-options-mac-shared-directories/\n\u003cbr\u003e[10] \u003cem\u003eResource management in Docker\u003c/em\u003e (September, 2014). Marek Goldmann.\nhttps://goldmann.pl/blog/2014/09/11/resource-management-in-docker/\n\u003cbr\u003e    \u003cem\u003eGathering LXC and Docker Containers Metrics\u003c/em\u003e (October, 2013). Jérôme Petazzoni.\nhttp://blog.docker.com/2013/10/gathering-lxc-docker-containers-metrics/\n\u003cbr\u003e[11] \u003cem\u003eRemoving SUID and SGID flags off binaries\u003c/em\u003e (August, 2008). Eric Thern.\nhttp://www.thern.org/projects/linux-lecture/intro-to-linux/node10.html\n\u003cbr\u003e[12] \u003cem\u003eAnnouncing Docker 1.2.0\u003c/em\u003e (August, 2014). Victor Vieux.\nhttp://blog.docker.com/2014/08/announcing-docker-1-2-0/\n\u003cbr\u003e[13] \u003cem\u003eHaving non-root privileges on the host and root inside the container #2918\u003c/em\u003e (November, 2013). [GitHub issue]\nhttps://github.com/docker/docker/issues/2918\n\u003cbr\u003e    \u003cem\u003eSupport for user namespaces #4572\u003c/em\u003e (March 2014). [GitHub issue]\nhttps://github.com/docker/docker/pull/4572\n\u003cbr\u003e    \u003cem\u003eProposal: Support for user namespaces #7906\u003c/em\u003e (September, 2014). [GitHub issue]\nhttps://github.com/docker/docker/issues/7906\n\u003cbr\u003e    \u003cem\u003eIssue 8447: syscall, os/exec: Support for User Namespaces\u003c/em\u003e (July, 2014) [Google Code issue]\nhttps://code.google.com/p/go/issues/detail?id=8447\n\u003cbr\u003e[14] \u003cem\u003eIntroduction to unprivileged containers\u003c/em\u003e (January, 2014). Stéphane Graber\nhttps://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/\n\u003cbr\u003e[15] \u003cem\u003eDocker 0.9: Introducing Execution Drivers and libcontainer\u003c/em\u003e (March, 2014). Solomon Hykes\nhttp://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/\n\u003cbr\u003e[16] A simple helper script to help people build seccomp profiles for Docker/LXC (November 2013). Martijn van Oosterhout.\nhttps://github.com/docker/docker/blob/487a417d9fd074d0e78876072c7d1ebfd398ea7a/contrib/mkseccomp.pl\n\u003cbr\u003e    https://github.com/docker/docker/blob/487a417d9fd074d0e78876072c7d1ebfd398ea7a/contrib/mkseccomp.sample\n\u003cbr\u003e[17] \u003cem\u003eAnnouncing Docker 1.2.0\u003c/em\u003e (August, 2014). Victor Vieux.\nhttp://blog.docker.com/2014/08/announcing-docker-1-2-0/\n\u003cbr\u003e[18] \u003cem\u003eDocker Container Breakout Proof-of-Concept Exploit\u003c/em\u003e (June, 2014). James Turnbull\nhttp://blog.docker.com/2014/06/docker-container-breakout-proof-of-concept-exploit/\n\u003cbr\u003e[19] docker2docker GitHub repository. Jérôme Petazzoni.\nhttps://github.com/jpetazzo/docker2docker\n\u003cbr\u003e\n\u003ch2\u003eLicense\u003c/h2\u003e\n\u003ca rel=\"license\" href=\"http://creativecommons.org/licenses/by-sa/4.0/\"\u003e\u003cimg alt=\"Creative Commons License\" style=\"border-width:0\" src=\"https://i.creativecommons.org/l/by-sa/4.0/88x31.png\" /\u003e\u003c/a\u003e\u003cbr /\u003e\u003cspan xmlns:dct=\"http://purl.org/dc/terms/\" property=\"dct:title\"\u003eDocker Secure Deployment Guidelines\u003c/span\u003e by \u003ca xmlns:cc=\"http://creativecommons.org/ns#\" href=\"https://github.com/GDSSecurity/MAM-Security-Checklist\" property=\"cc:attributionName\" rel=\"cc:attributionURL\"\u003eGotham Digital Science\u003c/a\u003e is licensed under a \u003ca rel=\"license\" href=\"http://creativecommons.org/licenses/by-sa/4.0/\"\u003eCreative Commons Attribution-ShareAlike 4.0 International License\u003c/a\u003e.\n\n\u003c/body\u003e\n\u003c/html\u003e\n","funding_links":[],"categories":["Security","Others","Others (1002)"],"sub_categories":["Monitoring Services"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FAonCyberLabs%2FDocker-Secure-Deployment-Guidelines","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FAonCyberLabs%2FDocker-Secure-Deployment-Guidelines","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FAonCyberLabs%2FDocker-Secure-Deployment-Guidelines/lists"}