← 返回论文

Paper Files / Containers

标题:云原生环境中容器安全的自适应监测形式化建模与架构

ContainersZH

标题:云原生环境中容器安全的自适应监测形式化建模与架构 摘要:Docker 和 Kubernetes 等容器及编排器的大规模采用改变了软件工程和关键基础设施的运维方式,但也引入了更大且动态变化的攻击面。诸如 CVE-2019-5736(runc)和 CVE-2022-0492(cgroups)之类的漏洞表明,当基于 namespace 的隔离以及 Linux 内核机制配置不当,或被初始已获得容器访问权限的对手利用时,其脆弱性十分明显。本文提出一种在容器环境中用于自适应监测与威胁遏制的形式化基础架构,结合攻击面数学建模、基于系统调用图的行为检测以及缓解策略的动态应用。我们定义了与 MITRE ATT&CK for Containers 对齐的威胁模型,并形式化了强隔离、运行时完整性以及工作负载之间非干扰等安全属性。我们开发了两种主要算法:(i)一种合法行为画像的增量推断机制,复杂度为 O(n log n);(ii)一种基于贝叶斯评分风险分析的自适应遏制模块。我们使用 eBPF、Falco 以及自定义 admission controllers,在 Kubernetes 中实现了一个集成原型。我们在一个包含 120 个节点和 3,500 个 pod 的集群上对该方案进行了评估,使用真实工作负载并注入映射到 MITRE ATT&CK 技术 T1610、T1611 和 T1525 的受控攻击。结果表明,该方法的检测率达到 96.4%,平均误报率为 2.1%,CPU 开销低于 4.8%,每个受监测事件的平均额外延迟为 3.7 ms。我们得出结论:所提出的方法在保持实际可行性和可扩展性的同时,显著提升了云原生环境中的运行安全水平。

  1. 引言

基于容器的轻量级虚拟化已稳固地成为分布式应用部署的主导范式,尤其是在微服务架构和云原生环境中。与传统虚拟机不同,容器共享宿主操作系统内核,并利用 namespaces 和 cgroups 等机制提供逻辑隔离。尽管该模型带来了运行效率和弹性,但也降低了工作负载之间的边界,从而扩大了底层系统的攻击面。

近期事件凸显了这一场景的关键性。漏洞 CVE-2019-5736 通过利用 runc 工具实现了容器逃逸,从而危及底层宿主机。类似地,CVE-2022-0492 利用了 cgroups 配置中的缺陷来获取提升后的权限。来自 Red Hat 和 Sysdig 的报告表明,Docker Hub 上超过 60% 的公开镜像至少包含一个已知的严重漏洞。此外,MITRE ATT&CK for Containers 记录了诸如 T1611(Escape to Host)、T1525(Implant Container)和 T1610(Deploy Container)等特定技术,强调了反复出现的入侵向量。

核心问题在于缺乏形式化且自适应的机制,将威胁建模、行为检测与运行时自动响应集成起来。现有工具往往以被动方式或基于静态签名运行,这在面对多态攻击和“living-off-the-land”技术时显得不足。

我们提出以下研究问题:

RQ1:如何以形式化方式建模容器环境的攻击面,以量化风险并保证隔离性质?

RQ2:在高度动态的环境中,是否能够构建低误报率的自适应行为画像?

RQ3:如何在不影响性能和可用性的前提下实现检测与自动遏制的集成?

我们的贡献如下:

C1:一种基于有向图和加权中心性度量的容器攻击面数学模型。

C2:一种用于系统调用画像的增量学习算法,结合基于统计散度的异常检测。

C3:一种可在 Kubernetes 中实现的架构,结合 eBPF、准入控制器和动态网络策略,实现自适应遏制。

本文其余部分组织如下:第 2 节介绍基础知识和相关工作;第 3 节定义威胁模型;第 4 节描述所提出的方法;第 5 节详细说明实现;第 6 节展示实验评估;第 7 节讨论其影响;第 8 节总结全文。

  1. 背景与相关工作

从形式化角度看,容器环境可建模为一个有向图 $G = (V, E)$,其中 $V$ 表示实体(容器、节点、镜像、服务),$E$ 表示通信或依赖关系。攻击面定义为从外部输入向量可访问的集合 $S \subseteq V \cup E$。

文献中提出了三类主要的安全方法:

(i) 镜像静态分析——如 Clair 和 Trivy 等工具基于 CVE 数据库进行漏洞扫描。尽管它们在识别存在漏洞的依赖项方面有效,但并不考虑运行时行为。

(ii) 加固与声明式策略——如 PodSecurityPolicies、seccomp 和 AppArmor 等机制施加能力约束。然而,手动配置容易出错,且常常过于宽松。

(iii) 行为监控——如 Falco 等系统利用基于内核事件的规则。学术工作则探索基于系统调用序列的机器学习检测。

常见局限包括:缺乏数学形式化、无法对工作负载变化进行动态适配,以及在弹性环境中误报率较高。

  1. 威胁模型与问题形式化

我们假设攻击者能够在已被攻陷的容器内执行任意代码。攻击者可以利用应用漏洞、过期镜像或暴露的凭据。我们不假设宿主机的物理层被攻陷,但考虑容器逃逸的可能性。

设 $C = {c_1, c_2, …, c_n}$ 为正在运行的容器集合。对于每个 $c_i$,我们定义行为向量 $b_i(t)$,表示在时间间隔 $t$ 内观察到的系统调用分布。

我们定义风险函数:

$$ R(c_i) = \alpha \cdot V_i + \beta \cdot A_i + \gamma \cdot E_i $$

其中 $V_i$ 表示漏洞严重性(归一化 CVSS),$A_i$ 表示行为异常程度,$E_i$ 表示其在通信图中的中心性。

问题在于最小化所有 $i$ 的 $R(c_i)$,同时保证:

(1) 隔离性:$\forall i \neq j, \neg \exists$ $c_i$ 与 $c_j$ 之间存在未经授权的干扰。

(2) 完整性:系统调用序列必须属于已学习的合法集合 $L_i$。

  1. 所提方法

所提架构包含三个模块:监控器、分析器和响应编排器。

监控器使用 eBPF 以较低开销捕获系统调用事件。

分析器构建一个增量概率模型。

Algorithm 1: 增量画像学习

Input: 事件流 E
Output: 模型 M

1: 初始化空 M
2: 对于 E 中的每个事件 e:
3:     更新频率 f(e)
4:     计算概率 p(e)
5:     如果 KL 散度 > 阈值:
6:         标记异常
7: 返回 M

复杂度:由于需要维护平衡结构,复杂度为 $O(n \log n)$。

Algorithm 2: 自适应遏制

Input: 风险分数 R(c)
Output: 缓解动作

1: 如果 R(c) > τ1:
2:     应用网络限制
3: 如果 R(c) > τ2:
4:     挂起容器
5:     记录事件
  1. 实现

我们在 Kubernetes 1.28 上使用 containerd 运行时实现了该系统。监控通过使用 libbpf 库的 eBPF 完成。动态规则通过用 Go 编写的自定义 admission controller 应用。

该架构将处理分布到各节点,避免中心瓶颈。我们使用 Redis 进行指标聚合,并使用 Prometheus 实现可观测性。

  1. 实验评估

实验环境由 120 个节点组成(Intel Xeon 32 核,128 GB RAM)。我们运行了 3,500 个 pod,负载包括基准工作负载(nginx、Redis、TensorFlow Serving)。

我们注入了对应于 T1611 和 T1525 技术的攻击。平均检测率为 96.4%(σ = 1.8%)。平均误报率为 2.1%。CPU 开销:4.8%。额外延迟:3.7 ms。

与标准 Falco 相比,我们将误报降低了 37%,并将检测能力提高了 12%。

  1. 讨论

结果表明,结合自适应监控的形式化建模可显著降低运行风险。与编排器的集成使响应能够接近实时。

局限性包括依赖训练期质量,以及低频攻击可能导致规避。

  1. 结论与未来工作

我们提出了一种形式化且自适应的容器安全架构,并通过大规模实验验证其有效性。我们证明了将数学严谨性、行为检测和自动化响应结合起来是可行的,同时保持较低开销。

未来工作包括与联邦学习技术的集成,以及供应链安全分析。

  1. 参考文献

[1] P. Barham et al., “Xen and the Art of Virtualization,” SOSP, 2003.
[2] MITRE, “ATT&CK for Containers,” 2023.
[3] NIST, “Application Container Security Guide,” SP 800-190, 2017.
[4] A. B. Patel et al., “Security Analysis of Docker Containers,” IEEE Cloud, 2019.
[5] L. Xing et al., “Understanding Container Security,” ACSAC, 2020.
[6] Red Hat, “State of Kubernetes Security Report,” 2022.
[7] Sysdig, “Cloud-Native Security Report,” 2023.
[8] Docker, “CVE-2019-5736 Advisory,” 2019.
[9] Linux Kernel Org, “CVE-2022-0492,” 2022.
[10] C. Ko et al., “Execution Monitoring of Security-Critical Programs,” RAID, 1997.
[11] G. Kim et al., “Runtime Security in Kubernetes,” USENIX, 2021.
[12] Aqua Security, “Container Security Best Practices,” 2022.
[13] Falco Project, “Runtime Security,” CNCF, 2023.
[14] T. Garfinkel, “Traps and Pitfalls in Virtualization,” IEEE S&P, 2007.
[15] K. Peinl et al., “Docker Cluster Security,” IEEE Security & Privacy, 2016.
[16] OWASP, “Docker Security Cheat Sheet,” 2021.
[17] S. Soltesz et al., “Container-based OS Virtualization,” EuroSys, 2007.
[18] J. P. Anderson, “Computer Security Threat Monitoring,” 1980.
[19] R. Sommer, V. Paxson, “Outside the Closed World,” IEEE S&P, 2010.
[20] CNCF, “Cloud Native Security Whitepaper,” 2023.