2022 云原生安全发展 24 个洞见

今天，云原生技术为企业带来快速交付的优势之外,也带来了新的安全要求与挑战。一方面，新技术（容器、编排、DevOps、微服务）的引入带来了新安全问题，如镜像的供应链问题、容器的逃逸问题、集群的横向移动问题、微服务的边界问题等，需要引入新的安全防护手段；另一方面，云原生持续开发/集成的开发模式的转变，传统安全无法适配新的开发节奏和安全要求。

在长期跟踪容器安全的研究之后，本文基于各类材料，重点对容器发展、容器镜像安全、K8S 发展的技术趋势进行整理分析，与各位业内安全同仁分享，为守护云原生安全的发展贡献一份力量。

01 容器生态发展 8 大洞见

与传统部署相比，安全专家和管理员在容器化环境中需要保护的组件更多、更复杂，涉及容器和底层基础设施，需要将安全集成到开发管道中，才能确保所有组件从最初的开发阶段到其生命周期结束都受到保护。

洞见 1：超过一半的组织运行容器数量大于 250 个，有 6%的人管理超过 5,000 个容器（如图 1 所示）。这表明越来越多的工作负载正在转向容器并远离传统架构。

图 1 运行容器的数量

洞见 2：每台主机上容器数量中位数都有所增加，2020 年同比增长了 33%，2021 年同比增长 12%，达到了 46 个（如图 2 所示），许多组织正受益于硬件资源利用率的提高。

图 2 每个主机上容器数量中值

洞见 3：大约 44%容器存活时间不到五分钟（如图 3 所示），许多容器只需要足够长的时间来执行一个函数，几秒钟可能看起来很短，但对于某些流程来说已足够。这表明容器的短暂性仍然是该技术的独特优势之一，但也带来了新的挑战，包括监控、安全性和合规性等新问题。

图 3 容器的生命周期

洞见 4：在容器运行时使用上，Docker 采用占 46%，首次跌破 50%，但 Docker 仍然是组织中使用最多的容器运行时（如图 4 所示）。

图 4 容器运行时

洞见 5：在容器仓库的使用上，Quay 首次超过 Docker，占客户采用率的 26%（如图 5 所示）。

图 5 容器镜像仓库

洞见 6：在资源使用限制上，60%的容器没有定义 CPU 限制，51%没有定义内存限制。即使在有 CPU 限制的集群中，平均有 34%的 CPU 内核未被使用（如图 6 所示）。

图 6 容器容量规划

洞见 7：在开源软件使用上，基于容器的应用开发中，使用前 12 种开源技术（如图 7 所示），排名前三是 NGINX、GO 和 JMX。

图 7 容器开源软件

洞见 8：容器化服务正在不断改进（如图 8 所示），使用寿命保持相对稳定，其中 31%服务周期超过 2 周。

图 8 容器化服务周期

扫描二维码，可获取《容器安全成熟度验证标准.pdf》

02 容器镜像安全态势 8 大洞见

随着组织将更多的容器工作负载转移到生产中，我们看到需要将安全性和合规性集成到 DevOps 工作流程中。容器镜像在容器安全中起着至关重要的作用。从镜像创建的任何容器都会继承其所有特征，包括安全漏洞、错误配置，甚至恶意软件。

洞见 1：76%的镜像最终以 root 身份运行（如图 9 所示）。

图 9 以 root 身份运行的容器

洞见 2：公共镜像仓库越来越受到信任，从 2020 年的 47%增加到 2021 年的 61%（如图 10 所示）。

图 10 镜像仓库拉取（公有仓库 vs 私有仓库）

洞见 3：RHEL 是迄今为止最受欢迎的基础镜像，占使用基础镜像的 36%，只有 25%的人使用 Alpine（如图 11 所示）。通过使用像 Alpine 这样的精简基础镜像，可以减少容器的攻击面。

图 11 基本镜像操作系统

洞见 4：镜像生命周期数据反映了代码发布之间的时间变化（如图 12 所示），大约一半的容器镜像在一周或更短的时间内被替换。

图 12 容器镜像生命周期

洞见 5：在容器工作负载中，在 62%容器中检测到 shell，38%检测到使用敏感挂载点启动的容器（如图 13 所示），这意味着该容器能够更改主机系统上的重要文件。

图 13 容器运行时安全警报

洞见 6：52%的镜像是在运行时扫描的，42%是在 CI/CD 管道中进行最初扫描的（如图 14 所示）。青藤建议在镜像生产、分发、运行阶段都需要不断重新扫描所有容器，以发现任何新披露的漏洞。

图 14 扫描镜像的位置

洞见 7：在生产环境中，运行的 85%的镜像至少包含一个可修补漏洞。此外，75%的镜像包含“高”或“严重”的可修补漏洞（如图 15 所示）。

图 15 运行时可修补漏洞

洞见 8：在关注告警中，Kubernetes.node.ready 仍然是最常用的，其次是 CPU 使用率和正常运行时间指标（如图 16 所示）。

图 16 Top10 警报

03K8S 安全发展 8 大洞见

Kubernetes 在组织中的使用越来越成熟，它是一个复杂的平台，需要大量的配置和管理。为了保证 Kubernetes 工作负载的安全，需要通过实施安全措施来解决关键的架构漏洞和平台依赖。

Pod 是 Kubernetes 中最小的部署单元，由一个或多个容器组成。Pod 通常是网络攻击者在进行容器漏洞利用时的初始执行环境。鉴于此，我们应该加固 Pod 安全，让网络攻击者难以进行漏洞利用，并限制入侵所造成的影响范围。

洞见 1：在编排工具的使用上，Kubernetes 成为了绝对主流，K8S 的使用率高达 96%（如图 17 所示）。

图 17 编排工具

洞见 2：在过去两年中，每个组织的平均 Pod 数量翻了一番（如图 18 所示），Kubernetes 主机的平均数量也出现了类似的相对增长。

图 18 每个组织的 Pod 数量

洞见 3：整体上来看，大部分用户的集群数量比较少，49%只有 1 个集群，此外每个集群的节点数量相对较少，大部分都只有 1-5 个 Nodes，这表明许多企业仍处于早期使用 Kubernetes 的阶段（如图 19 所示）。未来企业会向更多集群和每个集群更多节点的方向转变。

图 19 集群数量和每个集群的节点数

洞见 4：每个集群的 Pod 数量显著增加，54%的组织在每个集群中运行 100 多个 Pod（如图 20 所示）。每个节点的平均 Pod 数量有所下降，这表明团队正在部署更多更小的节点来处理他们的工作负载。

图 20 集群 Pod 数和节点 Pod 数

洞见 5：Kubernetes 组织每台主机运行 16 个 Pod，而使用 ECS 的组织每台主机运行 5 个任务。2020-2021 年，这两种环境的数字保持一致，这表明组织正在寻找合适数量的 Pod 和任务来支持他们的应用程序。我们还发现 Kubernetes Pod 和 ECS 任务平均运行 1.5 个容器（如图 21 所示）。

图 21 每个环境的主机密度

洞见 6：Kubernetes 可以根据指标自动水平或垂直扩展 Pod，以构建高可用性和高性能的容器应用程序。横向扩展 Pod 的总数可确保应用程序能够支持需求波动，而垂直扩展单个 Pod 的 CPU 和内存有助于管理应用程序的整体性能和成本。大约 40%的 Kubernetes 组织使用 HPA（横向扩展），而使用 VPA（垂直扩展）的组织不到 1%（如图 22 所示）。

图 22 Kubernetes 自动扩展使用量的时间变化

洞见 7：组织平均使用 13 个 StatefulSet 和 28 个 PVC（Persistent Volume Claim）（如图 23 所示），这表明越来越依赖 Kubernetes 来支持包括有状态应用程序在内的各种工作负载。

图 23 Kubernetes Stateful Sets 和 PVC 的使用情况

洞见 8：Prometheus 广泛用于 Kubernetes、OpenShift 和 Istio 等项目的度量标准。在 JMX、StatsD 和 Prometheus 这三个主流解决方案中，Prometheus 连续第三年获得收益。与去年同期相比，Prometheus 指标的使用率从去年的 62%增加到 83%。随着新编程框架的使用范围扩大，JMX 指标（用于 Java 应用程序）和 StatsD 等替代方案继续下降，今年 JMX 急剧下降至仅 4%，而去年为 19%（如图 24 所示）。

图 24 指标类型的平均使用情况