Docker安全部署的17条建议,在不同环境下实现容器安全

问题导读
1、你是如何构建docker image的？
2、你如何看待docker镜像的安全？
3、实现docker镜像安全有哪些方法？







在当前不断增长的基于云计算的IT市场，对虚拟化技术有大量的需求。遗憾的是大多数的虚拟化解决方案不足以去满足研发需求，全虚拟化解决方案产生的费用会变成可扩展的基础设施的隐含负担。

Docker允许开发人员和系统管理员为解决服务实际业务需求所需的应用和服务能够无缝部署容器以减少开销。无论怎样，因为Docker利用同一内核作为主系统以减少所需资源，容器如果没有进行充分配置则会明显的暴露安全问题。

下面逐项表明的强化措施可以保证在各自环境中提高容器的安全性。需要注意本提出方案仅适用去Linux Docker容器的部署在基于Linux的主机上，在编写本文时使用Docker最新的Release版本 (1.4.0, commit 4595d4f, dating 11/12/14)。

以下内容摘自Jérôme Petazzoni [1]和 Daniel J Walsh [2]发布的ppt和视频。本文的目标是如何具体地在Docker中实施。

注：大多数建议的命令行选项可以在一个类似于Dockerfile中存储并用于自动化镜像的构建。


1.Docker镜像

Docker 1.3 现在支持数字签名[3]来确认官方仓库镜像的起源和完整性。因该功能仍在开发中所以Docker将抛出警告但不会阻止镜像的实际运行。

通常确保镜像只从受信库中检索并且不使用—insecure-registry=[]命令项。

2.网络命名空间

在默认情况下，Docker REST API用来控制容器通过系统Docker守护进程是唯一能够通过Unix域套接字的方式暴露出来。在Docker上开启一个TCP端口（即 当引导Docker守护进程时必须使用 -H 选项绑定地址）将允许任何人通过该端口访问容器，有可能获得主机上的root访问权限以及在某些场景下本地用户所属的Docker组。

3.日志和审核

收集和归档与Docker相关的安全日志来达到审核和监督的目的。从host[8]，可以使用下面的命令来访问容器外的日志文件：

docker run -v /dev/log:/dev/log <container_name> /bin/sh
复制代码

使用Docker命令内置：

docker logs ... (-f to follow log output)
复制代码

日志文件也可以从持续存储导出到一个使用压缩包里面：

docker export ... 
复制代码

4.SELinux 或 AppArmor

Linux的内部安全模块，例如通过访问控制的安全策略来配置安全增强型Linux（SELinux）和AppArmor，从而实现强制性的访问控制（MAC）一套有限的系统资源的限制进程，如果先前已经安装和配置过SELinux，那么它可以使用setenforce 1在容器中被激活。Docker程序的SELinux支持是默认无效的，并且需要使用—selinux功能来被激活。通过使用新增的—security-opt来加载SELinux或者AppArmor的策略对容器的标签限制进行配置。该功能已经在Docker版本1.3[9]中介绍过。例如：

docker run --security-opt=secdriver:name:value -i -t centos bash 
复制代码

5.守护特权

不要使用--privileged命令行选项。这本来允许容器来访问主机上的所有设备，并为容器提供一个特定的LSM配置（例如SELinux或AppArmor），而这将给予如主机上运行的程序同样水平的访问。避免使用--privileged有助于减少主机泄露的攻击面和潜力。然而，这并不意味着程序将没有优先权的运行，当然这些优先权在最新的版本中还是必须的。发布新程序和容器的能力只能被赋予到值得信任的用户上。通过利用-u选项尽量减少容器内强制执行的权限。例如：

docker run -u <username> -it <container_name> /bin/bash 
复制代码

Docker组的任何用户部分可能最终从容器中的主机上获得根源。

6.cgroups

为了防止通过系统资源耗尽的DDoS攻击，可以使用特定的命令行参数被来进行一些资源限制。

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：

目前不支持Docker。BlockIO*属性可以通过systemd暴露，并且在支持操作系统中被用来控制磁盘的使用配额。

7.二进制SUID/GUID

SUID和GUID二进制文件不稳定的时候容易受到攻击，而这个时候是很危险的，，导致任意代码执行（如缓冲区溢出），因为它们会进程的文件所有者或组的上下文中运行。如果可能的话，禁止SUID和SGID使用特定的命令行参数来降低容器的功能。

docker run -it --rm --cap-drop SETUID --cap-drop SETGID ... 
复制代码

另一选择，可以考虑运用通过安装有nosuid属性的文件系统来移除掉SUID能力。

最后一个选择是从系统中彻底删除不需要的SUID和GUID二进制文件。这些类型的二进制文件可以在Linux系统中运行以下命令而找到：

find / -perm -4000 -exec ls -l {} \; 2>/dev/null 
 
find / -perm -2000 -exec ls -l {} \; 2>/dev/null 
复制代码

可以使用类似于下面的[11]命令将SUID和GUID文件权限删除然后：

sudo chmod u-s filename sudo chmod -R g-s directory 
复制代码

8.设备控制组(/dev/*)

如果需要，使用内置的设备选项（不使用-v与--privileged参数）。此功能在推出1.2版本[12]。

例如（声卡使用）：

docker run --device=/dev/snd:/dev/snd … 
复制代码

9.服务和应用

如果一个Docker容器有可能被泄露，为了减少横向运动的潜力，考虑隔离极易受影响的服务（如在主机或虚拟机上运行SSH服务）。此外，不要运行容器内不受信任的特许操作的应用程序。

10.安装项

当使用本机容器库时（即libcontainer）Docker就会自动处理这个。

但是，使用LXC容器库时，敏感的安装点最好通过运用只读权限来手动安装，其中包括：

/sys 
 
/proc/sys 
 
/proc/sysrq-trigger 
 
/proc/irq 
 
/proc/bus 
复制代码

安装权限应在以后删除，以防止重新挂载。

11.Linux内核

使用系统提供的更新工具来确保内核是实最新的（如apt-get，yum，等）。过时的内核可能更脆弱，并且被暴露一些漏洞。使用GRSEC或PAX来加强内核，即例如对内存破坏的漏洞来提供更高的安全性。

12.用户命名空间

Docker不支持用户的命名空间，但是目前的一个开发[13]功能。UID映射由LXC程序驱动，但在本机libcontainer库中不被支持。该功能将允许Docker程序像一个没有特权的用户在主机上运行，但显示出来的是和在容器中运行的一样。

13.libseccomp（和seccomp-bpf 扩展）

libseccomp库允许在基于一个白名单的方法上限制Linux内核的系统调用程序的使用。对于系统操作来说，不是很重要的系统调用程序，最好被禁用，以防止被破坏的容器被滥用或误用。

此功能目前工作正在进行中（LXC驱动程序中已经有了，但是在libcontainer中海没有完成，虽然现在是默认值）。使用LXC驱动程序[14]来重启Docker程序：

docker -d -e lxc 
复制代码

如何生成seccomp配置的说明都在“的contrib”[15]文件夹中的Docker GitHub的资源库。以后可以用下面的命令来创建一个基于Docker容器的LXC：

docker run --lxc-conf="lxc.seccomp=$file" <rest of arguments> 
复制代码

14.性能

只要可能，就将Linux性能降低到最小。Docker默认的功能包括：chown, dac_override, fowner, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, setfcap, and audit_write.

从控制行来启动容器时，可以通过下述来进行控制：

  --cap-add=[] 或者--cap-drop=[].
例如：

docker run --cap-drop setuid --cap-drop setgid -ti <container_name> /bin/sh 
复制代码

15.多租环境

由于Docker容器内核的共享性质，责任分离在多租户环境中不能安全地实现。建议容器在那些没有其它的目的，也不用于敏感操作的主机上运行。考可以虑通过Docker控制来将所有服务移动到容器中。如果可能的话，通过使用--icc= false将跨容器通信降到最低，并必要时指定-link与Docker运行，或通过—export=port，不在主机上发布，而在容器上暴露一个端口。相互信任的容器的映像组来分离机器[17]。

16.完全虚拟化

使用一个完整的虚拟化解决方案包含Docker,如KVM。这将阻止一个内核漏洞在Docker镜像中被利用导致容器扩为主系统。

Docker镜像能够嵌套来提供该KVM虚拟层，参考Docker-in-Docker utility [18]中所示。

17.安全审核

对你的主系统和容器定期进行安全审核以查明错误配置或漏洞，这些能使你的系统损坏。


########################################

本文档转载自：http://cloud.51cto.com/art/201501/464287.htm