容器安全五大风险

市场调研公司Allied Market Research估测，到2025年，容器应用市场的价值将从2016年的6.98亿美元增长到82亿美元。31.8%的复合年均增长率，很大程度上反映出应用容器技术正在飞速普及，公司企业也在加大云端迁移的步伐。

然而，应用容器的前景并非全然乐观。事实上，Allied Market Research发现，安全风险在一定程度上阻碍了应用容器市场的增长。而且，这样的风险还不会马上消失。因此，公司企业若想将容器技术纳入自身生产运营环境，就需要了解这些安全风险。

本文将特别围绕容器安全的五种风险展开讨论：启用微服务、依赖不安全基础镜像、容器可见性不完整、容器通信不受限、容器配置不安全。

启用微服务

CIO解释称，容器是由整个运行时环境（包括二进制文件、库和其他组件）构成的一类技术，从设计上就将各操作系统发行版的差异消弭于无形，因而开发运维团队可以很方便地利用容器分配资源和共享代码。

与容器一样，微服务也相当有用。但微服务主要是对开发人员有利。微服务为什么有利于开发？私有云服务提供商Gravitational将之归结为：微服务遵循的软件设计方法就是奔着完成小型任务去的。因而，开发团队能够利用微服务轻松部署代码，既不用中断其他团队成员的工作，也不用扩展他们的服务。

虽然各自独立，但容器和微服务是紧密相关的。容器有助于启用微服务，因为使用容器可以更轻松地将任务分解为较小的元素，并与其他团队成员共享。问题在于，微服务给公司企业带来了安全风险。微服务使用独立API相互通信，从而引入了可供恶意黑客入侵公司企业的其他渠道。微服务还引入了一些日志，安全人员可能会通过这些日志来筛选安全事件指征。但如果这些服务跨多台主机运行，则安全团队几乎无法手动管理这些日志。

依赖基础镜像

公司企业还需担心容器镜像的安全。容器镜像是包含可执行代码的静态文件，利用这些可执行代码，在公司企业的IT基础设施上作为独立的进程运行。

如果不甚清楚镜像来源，容器镜像的这种本质就会使这些资源变身安全风险。正如Kubernetes在其网站上指出的那样，从不熟悉的源提取容器镜像，无异于在计算机上运行未知软件。这种情形下，谁都不知道容器镜像能干出点儿什么来。隐藏恶意软件秘密盗取敏感信息？给恶意黑客分配网络访问权？都有可能。除此之外，已知安全漏洞也有可能令容器镜像元气大伤：如果没打补丁，这些漏洞可能为恶意黑客提供入侵容器环境所需的一切。

容器可见性

容器本就不是为了长期使用而设计的。公司企业使用容器，是想能够根据自身不断发展的需求旋上或旋下容器。采用容器技术，公司企业可以快速适应新兴业务需求，方便快捷地发布符合客户喜好的软件。

但这种动态性有其固有的风险，因为这样一来，公司企业就难以全面监测其整个容器环境了。不清楚自身环境中都有些什么，也就无法弄清该怎样恰当保护这些系统的安全。不仅如此，这种动态性也给合规造成了麻烦，因为传统静态IT资产的防火墙规则不适用于动态的容器环境。

容器通信

容器不是彼此隔离的。在网站的另一部分上，Kubernetes解释称，默认情况下不限制pod容器之间的通信流。这种配置使pod容器可以相互接收和发送流量。与之相对的，攻击者也能入侵一个pod，然后滥用此配置获取其他pod的权限。

容器配置

通信并不是公司企业在容器方面需要关注的唯一设置。还有配置问题。默认情况下，容器是可以获取新权限的。这些权限使得攻击者有可能滥用一个容器来染指容器环境的其他部分。

如何应对这些风险

如果实现容器安全最佳实践来解决上述风险。值得考虑的一些建议包括：

• 仅使用受信基础镜像来构建容器：公司企业需知道从何处获取容器，以及其中包含什么内容。
• 防止容器获取新权限：安全团队需专门设置此项控制，防止恶意黑客发起提权攻击。镜像中的setuid和setgid权限也应考虑删除。
• 采用镜像扫描策略：公司企业需经常扫描其各个镜像。作为扫描过程的一部分，应拒绝最近未经扫描的镜像进入构建阶段，或者重新扫描后再进入构建阶段。为简化操作，公司企业应将镜像扫描纳入治理策略中。