Docker容器技术发展如火如荼，相关的安全技术也在不断往前推进。我们也在继续探索容器技术应用与安全的问题，这个主题从传统安全角度出发，希望能给大家带来一些思考和讨论。

从传统的角度看，安全不单单是一个技术性的问题，更是一个意识的问题。

在云时代，服务上云已经非常普遍。而安全渗透攻击技术的自动化程度也到了很高水平，受攻击的目标变多，同时攻击者技术手段变高，使我们云端服务的安全环境变的不可预测。

按传统的云端部署方式，比如云台服务器+数据库+web+nginx模式，当出现安全告警时, 我们可以按部就班，升级内核、打补丁、升级服务等，基本上一切从容。

当我们将容器技术应用到部署运维时，打包迁移都是围绕docker, image，这种方式避免了我们在复制运行环境时发生漂移。而在没有处理惯例或者指引的情况下出现安全告警时，这种新的方式带来了新的安全性挑战。

传统攻击目标我们把它看成一个城池或城堡，容器是城池里的房间。传统方式通过信息收集、漏洞发现、渗透入侵等阶段进行系统渗透。

而从容器角度，从房间里边探知里面的信息，这些信息跟城池本身有一定的关联性或者是相似形，从而获取整个系统结构的秘密。

在渗透行为进行的过程中，漏洞对于后续的入侵过程尤为重要。反过来，对企业来说如何及时发现和处理系统漏洞是服务安全的重要部分。

无论是哪种漏洞类型，总会有一个生效周期。产品发布后，渗透人员发现漏洞，到提交漏洞库，或者0day无补丁漏洞。

厂商被通知或自行发现后进行补丁升级，然后是用户升级，更新软件或镜像，最后修补完成。从渗透人员发现漏洞到厂商升级并发布补丁，这段时间属于0day, 危害较大。

对应厂商升级，传统方式和容器有些不同，传统厂商，对相应服务维护升级比较及时，安全性较高。但对容器来说，限于基础镜像安全性，镜像来源也不同，现阶段对镜像的维护升级水平也参差不齐，安全性不可预测。

从全局策略来说，我觉得这一点是容器安全性受质疑的一个重要原因。

大概看一下国外牛人做的一些统计，说Docker Hub上官方的容器镜像有超过30%的数量，包含高风险的安全漏洞，其中有ssh的heartbleed和 bash破壳漏洞。如果对普通用户提交的镜像，这个比例超过40%，抽样误差在3%。

这些数据，是把这些镜像部署上，然后用脚本和公共漏洞数据库 CVE (Common Vulnerabilities and Exposures)对比查找出来的，这些CVE在相应的库里已经评级了，high,Medium,low。

第一组数据看起来还是很可怕的，因为高风险的镜像还是人们经常下载的镜像。然后第二组今年创建的image高危的镜像到40%，高危和中等能到75%，这个也可能是因为今年Docker活跃用户突增，镜像push数量大涨，并且镜像安全质量良莠不齐。最后一组是标有latest的，是image最近更新版，降了不少，这个也是说版本更新会解决一些问题。同时也是给我们提示，镜像最好用latest的，同时经常更新。

这个图是统计了非官方的镜像所用的package的数量对比，从这个图上看到排前三的是bash apt openssl , 这个估计是由于很多镜像用ubuntu基础镜像来的，也就是为什么镜像的漏洞里 bash ssh的占得比例比较大的原因。

列举几个近期的CVE

这几个是docker本身的问题，1.6.1版本的漏洞，基本上属于提权漏洞，只要通过精心设计的镜像就能够exploit。

除了这些CVE，Docker使用过程中也存在一些安全隐患。比如磁盘限额问题，docker本身没有这个功能，如果多租户模式下，某一个应用把磁盘给沾满了，消耗尽了，会严重影响其他容器应用的运行，需要通过辅助手段来解决。再就是超级权限—privileged, 它会赋予容器所有主机的root能力同时挂载所有设备。大家都知道，一般情况下不推荐使用。

我们需要看一下Docker本身的安全机制。Docker 本身使用内核的安全机制，包括Capability，Namespace, Cgroups。而SELinux/appArmor属于访问控制系列。

Capability用于限制容器所拥有的能力，也就是执行某些系统操作的权限，也可以根据需要对容器的能力进行增减。Namespace为每个容器提供隔离的系统运行环境，包括pid, network, uts, ipc, mount。Cgroup主要用于对容器所使用的资源进行限制，包括cpu,memory。技术措施上，对权限和资源进行限制，用cap-drop的方式来削减能力，利用cgroup来为容器添加cpu,和memory限制。这些对Docker比较了解的用户来说，应该耳熟能详了。

通过这些安全机制与参数设置，我们对docker本身能有一个基本的安全操控。Docker社区也在为自身的安全不断的努力。

首先，在开源社区，为代码贡献者指定了代码提交的指导原则，在开发过程中减少bug和漏洞，提高产品质量。同时定期对产品进行渗透测试，及时审计安全漏洞。并开放了相应平台，鼓励安全渗透人员提交漏洞。官方也提供了检测工具，专门为docker的部署运行环境做安全风险初评。

Docker Bench For Security是集成脚本，基本上会从几大方面进行初步检测：

1 – Host Configuration   docker检测分区位置，内核版本等是否符合标准
2 – Docker Daemon Configuration   检测Daemon配置，device driver, registry, TLS验证等
3 – Docker Daemon Configuration Files  检测相关文件权限
4 – Container Images and Build Files  容器用户检查，建议非root
5  – Container Runtime    容器SELinux/appArmor配置，资源限制及文件挂载权限等
6  – Docker Security Operations  其他安全选项

对于镜像image,Docker1.8.0版本提供了Docker Content Trust，允许在Docker Hub上下载container images之前检查其合法性。主要是用两个key，进行签名和验证，防止Image被中间篡改。

我认为对于使用者来说，应对容器安全问题，应该具有传统的安全思维同时采用新的技术手段。

除了上文中的具体安全设置，对于容器应用来说，策略上同样是三方面来实施：1.定期渗透测试，安全审计（同docker社区做法)）；2. 尽量采用image的正规镜像来源，相对于传统安全，容器安全受质疑很大程度上是在于镜像的维护及升级，因此在镜像源头保证安全和及时更新；3.及时升级容器服务，比如采用rollingupdate的方式对跑服务的容器进行升级等方式。

最后，虽然在安全上仍然存在问题，但我们看到，docker在开源社区的关注度、活跃度很高，贡献者也很多，大家群策群力，众人拾柴的情况下，docker容器技术的发展必然会越来越完善。存在的问题也会被逐步克服。

随着这项技术逐渐被大众接受并应用，云端容器应用逐渐会更广泛，再加上渗透安全人员对docker也慢慢熟悉，在未来一段时间内，docker的安全问题会有一个集中突增的时间。但随后docker进步与升级，再加上镜像安全机制的完善，安全问题也会随之慢慢减少。

Q&A精选：

1. 有没有可能做镜像安全性检测？至少基础类镜像。
答：恩，这个后面会提到，安全监测是应该的。

2. Docker Bench For Security是针对docker1.6的安全审计做的工具，不知道有没更新？
答：貌似更新了。当然，这些仅仅是对于docker的运行环境配置参数等进行的安全初评。要想对整个自身的系统服务进行检测，要用专用的渗透工具。

3. private registry 如何接入认证系统？现在只是在nginx上配了认证？
答：我们是docker index，不是nginx认证。可以看看我们在51CTO学院上的视频课程《深入浅出Docker Registry实战》。

4. 有没有很好的认证机制？
答：公开的镜像可以任意pull，除了程序自动验证，解析dockerfile能知道来源。

5. 内核及软件安全的问题是普遍的问题，主动权不在docker手上
答：对，所以docker的态度就是，我把我的代码质量把好关，时常给自己体检。而镜像问题就用策略防御。