从传统角度看Docker容器的安全性

  【雷竞技须安全稳定 服务器频道】当前持续增长的云计算市场对虚拟化技术有着强烈的需求。遗憾的是，大多数的虚拟化解决方案不够灵活，无法满足研发需求，且使用全虚拟化解决方案的潜在开销变成了制约基础设施扩展性的负担。

  Docker让开发和运维人员能无缝地部署容器，用于运行业务所需的应用与服务，从而减少这类开销。然而，因为Docker与宿主系统使用同一内核，配置不当的容器将造成重大安全隐患。

  Docker容器技术发展如火如荼，相关的安全技术也在不断往前推进。从传统的角度看，安全不单单是一个技术性的问题，更是一个意识的问题。在云时代，服务上云已经非常普遍。而安全渗透攻击技术的自动化程度也到了很高水平，受攻击的目标变多，同时攻击者技术手段变高，使我们云端服务的安全环境变的不可预测。

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

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

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

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

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

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

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

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

  Docker并不是虚拟机，Docker本来的用法也不是虚拟机。举个简单的例子，普通的虚拟机租户root和宿主root是分开的，而Docker的租户root和宿主root是同一个root。一旦容器内的用户从普通用户权限提升为root权限，他就直接具备了宿主机的root权限，进而进行几乎无限制的操作。

  Capability用于限制容器所拥有的能力，也就是执行某些系统操作的权限，也可以根据需要对容器的能力进行增减。Namespace为每个容器提供隔离的系统运行环境。Cgroup主要用于对容器所使用的资源进行限制。技术措施上，对权限和资源进行限制，利用cgroup来为容器添加CPU和内存限制。

  通过这些安全机制与参数设置，我们对Docker本身能有一个基本的安全操控。Docker社区也在为自身的安全不断的努力。首先，在开源社区，为代码贡献者指定了代码提交的指导原则，在开发过程中减少Bug和漏洞，提高产品质量。同时定期对产品进行渗透测试，及时审计安全漏洞。并开放了相应平台，鼓励安全渗透人员提交漏洞。官方也提供了检测工具，专门为Docker的部署运行环境做安全风险初评。

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

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

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