容器彻底改变了开发过程，是DevOps行动的基石，但容器带来了复杂的安全风险，而这些风险并不总是那么明显。不降低这些风险的组织很容易受到攻击。
本文概述了容器是如何促进敏捷开发的，容器带来了那些独特的安全风险，以及企业可以怎么做来保护容器的工作负载，超越DevOps来实现DevSecOps。
为什么容器如此迅速地流行起来?
容器在很多方面都是虚拟化的演进，用来加快开发过程，创建从开发到测试和实施的更敏捷的路线，这种方法比使用成熟的虚拟机更轻量级。
这个问题的核心是应用程序兼容性，因为应用程序需要某些版本的库，可能与其他应用程序的要求发生冲突。容器解决了这个问题，并且恰好可以与开发流程和驱动这些流程的管理基础设施很好地联系起来。
容器通过将虚拟化提升到一个新的层次来完成它们的工作。虚拟化抽象了硬件层，而容器抽象了操作系统层，本质上虚拟化了操作系统的角色。容器化的工作原理是将应用程序打包到“容器”中，其中包含了使应用程序运行所需的所有库，同时使应用程序之间互不知晓，因为每个应用程序都认为它拥有自己的操作系统。
从功能上讲，容器非常简单。容器只是一个文本文件，其概述了实例中包含哪些组件。容器的这种简单性和更轻量级的特性使得在整个开发生命周期中进行部署和使用自动化(编制)工具变得容易。
利于DevOps，但安全也很重要
容器有能力显著提高开发效率，这可能是容器如此广泛流行的主要原因之一。据Gartner估计，到2023年，70%的组织将运行容器化工作负载。
过去，开发、测试和部署应用程序的过程充满了障碍，开发人员和负责基础设施的团队之间经常来回反复。今天，通过使用容器，开发人员可以在一个有效的环境中构建和测试，并且只需将完成的代码与定义该环境的规范一起发布。
在操作方面，团队只需执行此规范即可创建一个可供使用的匹配环境。
所以，DevOps意味着快速发展。但是缺少一个组件：安全性。这就是为什么我们越来越多地听到DevSecOps从DevOps演变而来的原因，因为开发人员已经注意到，仅凭DevOps模型不足以解决安全问题。
容器引入了几个安全风险
容器简化了开发过程，但在安全性方面引入了复杂性。当您将整个操作环境紧密地封装到一个容器中，只是为了广泛地分发它时，同时也会增加攻击面并为不同的攻击向量打开了大门。与容器一起打包的任何易受攻击的库都会将这些漏洞传播到无数工作负载中。其中的风险包括：
1. 供应链攻击
恶意攻击者不是通过影响应用程序，而是通过修改与应用程序一起提供的包或组件来发起攻击。因此负责开发的团队需要检测其正在开发的应用程序及容器配置作为依赖项引入的库的安全性。可以用到的自动化工具如SAST、SCA等，可以协助开发人员及时发现代码安全漏洞及开源组件成分中的风险隐患。
2. 启用容器的其他工具
容器安全的风险还涉及启用容器的工具，从 Docker到Kubernetes等编排工具。因为这些工具需要被监控和保护。例如，不允许系统管理员以root身份运行Docker容器。同样，需要密切保护容器注册表，以确保它们不会受到损害。
内核安全是容器安全的核心
与容器相关的一些安全风险比其他风险更不明显。每个容器都需要访问内核——毕竟，容器只是一种高级进程隔离。但是很容易忽略这样一个事实:所有的容器都依赖于同一个内核——容器内的应用程序彼此隔离并不重要。
应用程序在容器中看到的内核与主机所依赖的内核是相同的。这带来了一些问题。如果支持容器的主机上的内核容易被利用，则可以通过从容器内的应用程序启动攻击来利用此漏洞。
因此，意味着必须迅速修补有缺陷的内核，否则所有容器都可能很快受到漏洞的影响。
修补漏洞
因此，使主机的内核保持最新是确保容器操作安全的重要一步。不仅需要修补内核，应该修补容器中引入的库。但是，正如我们所知，持续修补说起来容易做起来难。这可能就是为什么一项研究发现所分析的容器中有75%的缺陷被归类为严重或高风险的漏洞。
例如，这些漏洞可能导致爆发攻击，攻击者依赖容器内有缺陷的库来在容器外执行代码。通过破坏一个容器，攻击者最终可以到达他们的预期目标，无论是主机系统还是容器中的其他应用程序。
在容器的上下文中，维护安全的库可能是一件非常头痛的事情，这需要有人跟踪跟踪新漏洞以及已修补和未修补的漏洞。
将安全始终贯穿于容器操作和使用中
当涉及到信息安全时，尖端技术通常会引入新的复杂性。新的工具通常会导致新的漏洞利用。对于容器也是如此，虽然它不会削弱在工作负载中使用容器的整体价值，但需要密切关注容器带来的风险。
了解容器安全性中常见缺陷及缓解缺陷的实践。除了打补丁，通过采取正确的方法来减少网络安全漏洞和缺陷有助于保护企业网络安全。
文章来源：
