翻译自 Container Security 101: A Guide to Safe and Efficient Operations 。
容器是交付云原生应用程序的事实标准。以下是有关它们所带来的安全风险以及采取哪些对策来保护它们的指南。
这篇文章是 KubeCon + CloudNativeCon Europe 2023 预览系列的一部分,该活动将于 4 月 18 日至 21 日在阿姆斯特丹举行。加入我们,了解更多关于云原生应用程序和开源软件的变革性质。
在过去的几年里,容器的采用彻底改变了一切。容器成为软件部署的事实标准,提供了广泛的优势,例如:
在我们深入讨论技术细节之前,让我们通过简要回顾容器在软件开发上下文中的含义来确保我们理解一致。
容器是使用专用资源运行的系统进程(从主机的角度来看)。现在,下一个可能出现的逻辑问题可能是:这些容器是如何创建的?
回答这个问题可以让我们进一步理解本文主题的核心。
容器是从 OCI 镜像生成的,这些镜像包括以容器化方式运行应用程序所需的元素,例如代码、配置文件、环境变量、库以及描述其需求和能力的元数据。
容器生成中最常见的场景是开发人员依赖从公共注册表中获取的基础映像,并将开发的软件添加到其中。
开发人员可以使用不同类型的基础镜像;它们可以是“简单的”,如基本操作系统镜像,也可以是“复杂的”,并且已经包含特定系统库或工具等信息。
正如“魔鬼藏在细节中”,DevSecOps 也是如此。
确保选定的基础镜像在执行时不会产生任何安全影响可能具有挑战性,尤其是当您依赖“复杂”镜像时。
让我们从基础开始:意识到风险是采取对策的良好起点。
开发人员可以从不同的来源拉取基础镜像来构建他们的容器,主要来自公共 registry ,例如:
其他常见来源是 git 仓库,开发人员可以在其中轻松找到包含构建所需说明的 Docker 文件。
这是开源力量的一个很好的例子,因为它使每个人都可以从别人的工作开始构建自己的镜像。
缺点是在生产中部署它们时需要考虑风险:
让我们深入了解这些问题,并介绍开发人员可以实施的最简单的最佳实践,以避免它们。
限制镜像带有恶意代码的风险的一个好方法是仅从官方来源或经过验证的开发人员处提取基础镜像。
知名的公共 registry 有许多经过验证的官方开发人员/公司,他们推送和维护更新的镜像。
以所有 registry 为例,它们都会定期进行漏洞扫描,提供有关当前检测到的漏洞的报告。
如果镜像没有经过定期扫描和修补处理,那么就没有官方仓库可以完全解决这个问题。
仅使用最近和定期更新的镜像可以减轻 Bug 和镜像配置错误。例如,从 Kubernetes 的安全角度来看,一个好的缓解措施可能是一个 admission webhook,它拒绝部署基于早于给定日期的镜像的容器。
. 在这个阶段,应该清楚的是,使用容器和镜像是一件令人兴奋的事情,但需要以正确的方式或至少有意识地进行。
不幸的是,在过去几年中,许多安全漏洞都被利用在受损的 CI/CD 供应链上,有时是由注入到图像中的恶意代码驱动的,有时是利用已知的 CVE。
在 2023 年,DevOps 绝对应该意识到这些风险,并相应地与内部安全团队合作以减轻这些风险。
现在情况很清楚了。我们怎样才能安全地生活,或者至少降低风险?
答案可能很长很复杂,并且取决于生产工作负载所需的安全级别。
一些基本的一级规则:
关于容器镜像的另一个重要建议是越小越好。
使用完整的操作系统作为基础容器镜像可能有助于故障排除,但镜像中更多的库和可执行文件也意味着更大的攻击面。
作为风险缓解,DevOps 应考虑使用最小的 Linux 基础镜像(如 Alpine)或无发行版容器镜像。
不过,请考虑一下,这种策略会使故障排除变得更加困难。仅在生产环境中使用最少的基础镜像可能是安全性(最重要的地方)和开发期间故障排除之间的良好折衷。
考虑到基础镜像的安全方面,随着时间的推移保持它们的更新和安全可能具有挑战性。通常,依靠可信来源、经过验证的注册表和使用更新的镜像就足够了,但情况并非总是如此。
如果容器化工作负载的高安全级别是强制性的,例如金融、保险或任何其他高风险环境,那么一个好主意可能是依赖提供安全、经过验证和定期更新镜像的专用服务。