docker安全性分析.docxVIP

在审查Docker的安全时，需要考虑三个主要方面：容器内在的安全性，由内核命名空间和cgroup中实现; docker守护程序本身的攻击面; 加固内核安全特性，以及它们如何与容器中互动。Docker并不是虚拟机，Docker本来的用法也不是虚拟机。普通的虚拟机租户root和宿主root是分开的，而Docker的租户root和宿主root是同一个root。一旦容器内的用户从普通用户权限提升为root权限，他就直接具备了宿主机的root权限，进而进行几乎无限制的操作。这是因为Docker原本的用法是将进程之间进行隔离，为进程或进程组创建隔离开的运行空间，目的就是为了隔离有问题的应用，而进程之间的限制就是通过namespace和cgroup来进行隔离与配额限制。每一个隔离出来的进程组，对外就表现为一个container（容器）。在宿主机上可以看到全部的进程，每个容器内的进程实际上对宿主机来说是一个进程树。也就是说，Docker是让用户以为他们占据了全部的资源，从而给用户一个“虚拟机”的感觉。安全策略SELinux或AppArmor通过访问控制的安全策略，可以配置Linux内核安全模块，如安全增强型Linux（SELinux）和AppArmor，从而实现强制性的访问控制（MAC）用以将进程约束在一套有限的系统资源或权限中。如果先前已经安装并配置过SELinux，那么可以在容器使用setenforce 1来启用它。Docker守护进程的SELinux功能默认是禁用的，需要使用--selinux-enabled来启用。容器的标签限制可使用新增的—-security-opt加载SELinux或者AppArmor的策略进行配置，该功能在Docker版本1.3引入。例如：docker?run?--security-opt=secdriver:name:value?-i?-t?centos?bashnamespaces和cgroupsDocker容器中非常相似LXC容器，它们都具有类似的安全功能。当以“docker run”启动一个容器，后台Docker为容器创建一组namespaces和cgroups。cgroups使用特定的命令行参数来启用一些资源限制，防止单一的容器用尽某个资源而使系统瘫痪：CPU：docker?run?-it?--rm?--cpuset=0,1?-c?2?... 内存：docker?run?-it?--rm?-m?128m?... 存储：docker?-d?--storage-opt?dm.basesize=5G 磁盘I/O挂载点使用原生容器库（如libcontainer）时，Docker会自动处理这项。但是，使用LXC容器库时，敏感的挂载点最好以只读权限手动挂载，包括：/sys/proc/sys /proc/sysrq-trigger/proc/irq/proc/bus 挂载权限应在之后移除，以防止重新挂载。Linux内核使用系统提供的更新工具（如apt-get、yum等）确保内核是最新的。过时的内核相比已公开的漏洞危险性更大。使用GRSEC或PAX来强化内核，例如针对内存破坏漏洞提供更高的安全性。libseccomp（和seccomp-bpf扩展）libseccomp库允许基于白名单方法来限制Linux内核的系统调用程序的使用。最好禁用受攻击容器中对于系统操作不是很重要的系统调用程序，以防止其被滥用或误用。此功能目前正在开发中（LXC驱动中存在，但是现在默认的libcontainer中没有）。使用LXC驱动程序[14]来重启Docker程序：docker?-d?-e?lxc如何生成seccomp配置的说明都在GitHub仓库的“contrib”文件夹。之后可用下面的命令来创建一个以LXC为基础的Docker容器：docker?run?--lxc-conf=lxc.seccomp=$file?rest?of?argumentsCapabilities尽可能降低Linux能力。Docker默认的能力包括：chown、dac_override、fowner、kill、setgid、setuid、setpcap、net_bind_service、net_raw、sys_chroot、mknod、setfcap、和audit_write`。在命令行启动容器时，可以通过--cap-add=[]或--cap-drop=[]进行控制。例如：docker?run?--cap-drop?setuid?--cap-drop?setgid?-ti?container_name?/bin/sh此功能在Docker 1.2版本引入。完全虚拟化使用一个完全虚拟化解决方案来容纳Docker，如KVM。如果容器内的内核漏洞被发现，这将防止其从容器扩大到