【摘   要】 随着容器技术的快速发展和广泛应用，其面临的安全问题也越来越突出。本文在分析开源容器技术典型代表Docker和Kubernetes应用过程中面临的安全问题及挑战的基础上，提出应对建议。

【关键词】 容器技术 Docker Kubernetes 容器安全

1 引言

高德纳（Gartner）预测，到2023年，70%的组织将在生产中运行3个或更多容器化应用程序。容器、容器编排技术（Kubernetes，K8S）和微服务应用模式是企业IT创新和数字化转型的三大驱动力，很多公司已经采用这些技术，发挥其在应用程序开发和部署方面的优势。随着容器技术的快速发展和广泛应用，其面临的安全问题也越来越突出。本文在分析开源容器技术典型代表Docker和K8S应用过程中面临的安全问题及挑战的基础上，提出应对建议。

2 开源容器技术发展应用分析

相比于系统级虚拟化，容器技术是进程级别的，具有启动快、体积小等优势，为软件开发、应用部署带来了诸多便利。如使用开源容器Docker技术，应用程序打包推送到镜像中心后，使用时拉取直接运行，实现了“一次打包，到处运行”，非常方便、快捷；使用开源容器编排技术K8S能够实现应用程序的弹性扩容和自动化部署，满足企业灵活扩展信息系统的需求。但是，随着Docker和K8S应用的日益广泛和深入，安全问题也越来越凸显。

2.1 容器技术发展迅速且应用广泛

2013年，Docker公司提出Docker开源容器项目，随后发布了一系列工具链来支持容器使用；到2020年，Docker容器官方镜像仓库Docker Hub的镜像中心累计下载了1300亿次，用户创建了约600万个容器镜像库。Docker开源技术能实现对容器的治理和编排，已成为容器管理领域事实上的行业标准。根据云原生计算基金会于2020年3月发布的最新调查，在亚马逊公司云计算平台（Amazon Web Services，AWS）和谷歌公司云平台（Google Cloud Platform，GCP）的托管服务中，K8S的生产使用率从58%跃升至78%。

2.2 开源技术推动了容器技术发展

Docker技术和K8S技术之所以能够快速发展和广泛应用，除了技术本身的优势之外，重要的原因就是由于开源社区管理和支持。开源社区具有限制少、交付快捷、迭代快速、参与人员多、大公司支持等优势，大大促进了容器技术的演进。开源容器技术生态体系日趋完善，已贯穿现代化软件工程的整个生命周期，其复杂度也在不断提升。

2.3 基于容器技术的敏捷开发模式日趋流行

在移动应用、互联网背景下，企业竞争日趋激烈，应用程序快速迭代、持续交付显得尤为重要。容器技术的应用大大推动了软件交付模式的革新，基于容器的敏捷开发模式DevOps（开发运维一体化）大大提高了软件的交付速度、部署频率。常见的DevOps流程，包括拉取代码、代码构建、项目打包、Docker构建、拉取镜像和Docker运行6个步骤，通过多种工具的集成，构成了自动化DevOps开发运维流水线，开发人员提交的代码能够自动部署到生产环境，如图1所示。

DevOps生命周期是以下各项工作的反复迭代：计划、编码、构建、测试、发布、部署、运维、监控。从开发人员提交代码开始，直到在生产环境中运行，形成自动流水线过程；一旦运行，就反复迭代、循环运行。任一环节出现安全问题，就会影响开发、交付，同时也增加了安全控制的复杂度和难度。

基于容器技术的DevOps各个阶段都可能存在安全漏洞，应该实施安全控制措施，如构建时安全、基础镜像的安全、Docker基础设施安全、运行时安全等，要加强容器镜像扫描、容器编排

配置错误控制、网络身份访问管理、检测和事件响应等。

3 开源容器技术面临的安全挑战分析

2020年，Prevasio公司发布Docker容器官方镜像仓库Docker Hub分析报告：通过对400万容器镜像的扫描发现51%的镜像存在高危漏洞，6432个镜像包含病毒或恶意程序。

Docker容器技术应用中可能存在的技术性安全风险分为镜像安全风险、容器虚拟化安全风险、网络安全风险等类型。

Docker Hub中的镜像可由个人开发者上传，其数量丰富、版本多样，但质量参差不齐，甚至存在包含恶意漏洞的恶意镜像，因而可能存在较大的安全风险。具体而言，Docker镜像的安全风险分布在创建过程、获取来源、获取途径等方方面面。

与传统虚拟机相比，Docker容器不拥有独立的资源配置，且没有做到操作系统内核层面的隔离，因此可能存在资源隔离不彻底与资源限制不到位所导致的容器虚拟化安全风险。

网络安全风险是互联网中所有信息系统所面临的重要风险，不论是物理设备还是虚拟机，都存在难以完全规避的网络安全风险问题。而在轻量级虚拟化的容器网络和容器编排环境中，其网络安全风险较传统网络而言更为复杂严峻。

3.1 开源容器技术Docker面临的安全隐患

Docker的安全问题主要可能来源于3个方面。

3.1.1 Docker自身漏洞

Docker作为一款软件，自然也跟软件一样，技术实现上会有代码缺陷。MITRE公司共发布了134项Docker安全漏洞（截至2020年12月28日）。 编号CVE-2020-35467的安全漏洞显示，2020年12月14日之前的Docker Docs映像包含根用户的空白密码。使用受影响的Docker Docs容器版本部署的系统可能允许远程攻击者使用空白密码来实现根用户访问。该安全漏洞实际就是根用户的访问控制漏洞，攻击者很容易利用该漏洞实现越权访问。

3.1.2 Docker镜像源的安全问题

Docker提供了Docker Hub可以让用户上传创建的镜像，以便用户下载，快速搭建环境。但同时有一些安全问题需要应对，如Docker镜像存在黑客上传恶意镜像、镜像使用有漏洞的软件、中间人攻击篡改镜像等。这些问题都与我们在网络上下载软件所遇到的问题相同。

3.1.3 Docker架构缺陷与安全机制

Docker本身的架构与机制可能产生的攻击场景是在黑客已经控制了宿主机上的一些容器（或者通过在公有云上建立容器的方式获得这个条件）后，对宿主机或其他容器发起攻击来产生影响。存在容器之间的局域网攻击、耗尽资源造成拒绝服务攻击、调用有漏洞的系统、通过Docker提权等安全隐患。

3.2 开源容器编排技术K8S面临的安全隐患

3.2.1 容器之间通信带来的安全隐患

容器和Pod（K8S最小运行单元）需要在部署中相互通信，也需要与其他内部和外部端点通信才能正常工作。如果某个容器被破坏，攻击者可影响的环境范围与该容器的通信范围直接相关，这意味着与该容器通信的其他容器以及Pod可能会遭受攻击。

3.2.2 镜像带来的安全问题

K8S是对容器的管理和多个容器的编排、互操作，容器运行需要拉取镜像。因此容器镜像带来的安全问题在容器编排过程中依然存在，而且波及范围更广。

3.2.3 K8S本身的安全隐患

2020年，MITRE CVE发布30个K8S漏洞（截至2020年12月28日），这里举例以下典型漏洞。

编号CVE-2020-8558的漏洞：

发现版本1.1.0-1.16.10、1.17.0-1.17.6和1.18.0-1.18.3中的Kubelet和kube-proxy组件允许相邻主机访问TCP和UDP服务绑定到节点上或在节点的网络名称空间中运行的127.0.0.1。通常认为此类服务仅可由同一主机上的其他进程访问，但是由于这种缺陷，与该节点在同一LAN上的其他主机或与该服务在同一节点上运行的容器可以访问该服务。

编号CVE-2020-8557的漏洞：

版本1.1-1.16.12、1.17.0-1.17.8和1.18.0-1.18.5中的K8S kubelet组件不考虑Pod写入其自己的/etc/ hosts文件的磁盘使用情况。计算Pod的临时存储使用量时，kubelet刨除管理器不包括kubelet挂载在Pod中的/etc/ hosts文件。如果Pod将大量数据写入/etc/hosts文件，则可能会填充节点的存储空间并导致节点故障。

编号CVE-2020-8558的漏洞：

利用K8s节点之间网络访问控制的安全隐患造成的漏洞，没有实现主机之间的隔离造成安全隐患。

3.3 基于容器的开发交付机制安全问题

容器的使用为软件开发交付带来了便利，如DevOps模式。但由于种种原因，安全问题没有得到足够重视，例如：

（1）DevOps偏向于设计开发和交付，由于大量使用自动化流水线工具，安全人员没有及时参与；

（2）大多数安全人员不熟悉开发运维流水线中的常用工具，尤其是与其互操作和自动化流水线功能相关的技术；

（3）大多数安全人员不了解容器是什么，更不用说容器独特的安全问题是哪些了；

（4）安全常被视为与开发运维敏捷性相对立的东西，因为DevOps追求快速交付、持续交付，而从安全角度看，在快速交付的同时，应尽量落实安全控制；

（5）安全基础设施依然建立在硬件设计上，而硬件设计往往落后于软件定义和可编程性的概念，这就造成了很难将安全控制措施以自动化的方式集成到DevOps开发运维流水线的局面。

与其他新兴技术一样，容器和DevOps并非从一开始就将安全考虑了进去。在大多数企业中，容器和DevOps尚未纳入企业整体安全计划，但由于可能已经部署到了企业中某些地方，这些技术理应被当做需要保护的对象。

3.4 企业利用容器技术将面临新的发展机遇和安全问题

在传统企业如制造业中，智能制造、信息物理系统、数字孪生、物联网、5G等新兴信息技术正逐渐得到应用，容器技术能为新兴信息技术的利用注入活力，比如轻量化的容器能够为设备的数字化、智能化升级赋能。由于开源容器技术的易获得、易运行、易维护、易移植等优势，为传统企业的数字化转型提供了动能。同时，存在的安全问题也不能忽视，容器物理运行环境的安全、容器的故障恢复能力都应该得到关注；数据和数据流动的安全依然是企业应用容器技术的安全防护的重中之重，容器与传统技术不同，用户无须关心容器内部的运行情况，拉出应用程序直接运行即可，因此对于容器是否安全，数据和数据流动是否安全，用户“看”不出来，这无疑会造成容器是否能在企业安全落地的难题。

4 开源容器技术安全应对建议

4.1 开源容器技术安全的顶层设计和监管建议

目前，开源容器技术发展很快，应用也很广泛。但是我国尚未正式发布专门针对开源容器技术安全利用的相关规章制度。面对眼花缭乱的容器技术市场和琳琅满目的容器安全技术，普通开发者和用户很难分辨哪些镜像是安全的，哪些镜像是不安全的。因此，建议相关部门定期发布不安全的镜像信息；加强容器安全技术的授信，确保容器安全防护技术本身的安全可靠；对企业安全使用Docker和K8S技术提供具体指导意见。

4.2 开源容器使用的安全建议

开源容器在使用过程中，要从构建时、容器基础设施、运行时等方面进行安全控制的考虑。对此提出以下4点建议。

（1）强化容器运行环境（宿主机）的安全。底层操作系统应受到良好保护，以防止对容器的攻击影响到实体主机。对此，Linux有一些现成的安全模块可用。

（2）保护DevOps开发运维流水线。在整个开发运维流水线上应用特权管理操作，确保只有经授权的用户可以访问该环境，并限制未授权用户在环境中的横向移动。

（3）镜像的漏洞扫描。在运行前对容器镜像执行深度漏洞扫描。

（4）持续监测容器镜像。在运行时检测容器和托管主机中的root提权、端口扫描、逆向Shell和其他可疑活动，防止漏洞利用攻击和突破。

4.3 企业利用容器技术的安全建议

对于企业而言，利用容器技术时，建议围绕应用安全和数据安全开展工作。

（1）应用安全方面：①容器可视化：容器内部对企业而言是“黑盒”，要力图实现容器内部信息的外部可视化，把内部的业务逻辑和信息交互逻辑，通过可视化的形式展现给管理用户。②容器应用安全措施：规范镜像构建，实行镜像签名，建立镜像中心拉取等的操作审计日志，使用可信的容器镜像等。③强化管理：定义运营、开发、安全团队之间的角色。职责分离是一种最佳实践，应以明确的角色和责任记录在案。在DevOps的基础上，实施DevSecOps（开发—安全—运维一体化）。④DevSecOps：是指先在应用程序开发的生命周期中引入安全性，从而尽可能地减少漏洞并使安全性更接近IT和业务目标。构成真正的DevSecOps环境的3个关键因素是：安全测试由开发团队完成；测试期间发现的问题由开发团队管理；解决这些问题的责任在于开发团队。⑤连续身份认证和授权：容器应用一般都是通过流水线的形式进行开发、测试、发布、上线的，对于每个环节都要进行身份认证和授权，保证安全。⑥应用安全恢复：采取各种措施，保证应用具有快速恢复的能力，比如采用集群技术。

（2）数据安全方面：①数据存储：对于传统的事务型数据使用关系型数据库更易于管理，因此不建议纳入容器管理。②数据流动：通过身份认证和授权，保障数据安全和范围控制；数据按照重要程度进行分类；不同用户之间容器网络隔离。默认设置为：不同用户的容器与容器之间不能互相访问；同一用户的所有容器可以互相访问。③数据备份：做好数据备份工作。④宿主机挂载目录：用户通过统一运维管理平台，只能将固定目录挂载到容器中。⑤分布式文件系统：用户通过统一运维管理平台申请数据文件，通过apikey/secrekey访问平台提供的分布式文件。⑥数据故障恢复：采取集群技术，同时做好数据备份。

5 结语

开源容器技术如Docker、K8S等已广泛被应用于实际生产环境，随着我国云计算平台的快速发展，容器技术将获得更大范围、更深层次的应用。在一些传统行业，特别是制造业，将会迎来容器化技术带来的创新机遇。一方面我们要做好规划和设计，大力推进基于容器技术的应用创新；另一方面我们要加大对开源容器技术的安全漏洞防范，保护应用安全和数据安全。