← 返回论文

Paper Files / Containers

标题:CONTAINERSHIELD:一种基于多层遥测的容器环境威胁检测与缓解的形式化与实证框架

ContainersZH

标题:CONTAINERSHIELD:一种基于多层遥测的容器环境威胁检测与缓解的形式化与实证框架 摘要:在 Docker 和 Kubernetes 等平台推动下,容器的大规模采用改变了分布式系统架构,但也引入了一个复杂且高度动态的攻击面。镜像中的漏洞、namespace 和内核 capabilities 配置不当,以及逃逸和横向移动攻击,均已被系统性利用,近期的 CVE(例如 CVE-2019-5736、CVE-2022-0492)即为明证。本文提出 CONTAINERSHIELD,一种用于容器环境威胁检测与缓解的形式化与实证框架,基于多层遥测(内核、运行时和编排器)的相关分析。我们将环境形式化建模为带标记迁移系统,并定义以隔离、完整性和 capabilities 约束为表述的安全性质。我们开发了两个核心算法:(i)一种基于可变阶 Markov 链对行为进行概率建模的检测机制;以及(ii)一个策略验证模块,用于施加 Linux capabilities 和 seccomp 配置文件的动态约束。我们在 Kubernetes 1.28 上结合 eBPF 实现了该系统,并在一个包含 48 个节点(768 vCPU)的集群上进行了评估。利用真实负载和 27 个映射到 MITRE ATT&CK for Containers 的攻击场景,我们实现了 96.4%(±1.8%)的检测率、2.1% 的误报率,以及 3.7% 的平均 CPU 开销。与默认配置下的 Falco 和 Aqua Security 等工具相比,我们的方法将误报率降低了 38%,并将平均检测时间提升了 24%。我们证明,威胁建模与实时遥测之间的形式化集成可为运行安全提供更稳健的保障。CONTAINERSHIELD 为容器安全的严格系统化作出了贡献,为云原生环境中的保护提供了一条可扩展且可验证的路径。

  1. 引言

通过容器实现的轻量化虚拟化已确立为云计算中的主导范式,它借助 Linux 内核的 namespaces 和 cgroups 实现应用隔离。与传统虚拟机不同,容器共享同一内核,这降低了开销,但也扩大了共享攻击面。这一结构性特征使安全模型本质上依赖于操作系统的隔离机制,而这些机制一旦配置错误或被利用,可能同时危及多个工作负载。

近期事件凸显了该问题的严重性。漏洞 CVE-2019-5736 允许通过操纵运行时 runc 实现容器逃逸,从而可覆盖宿主机二进制文件。类似地,CVE-2022-0492 利用 cgroups 配置中的缺陷获取特权执行。诸如 TeamTNT 之类的攻击活动利用配置不当的 Kubernetes 环境进行加密货币挖矿,并采用与 MITRE ATT&CK 对应的技术,例如 T1611(Escape to Host)和 T1610(Deploy Container)。Red Hat 与 Sysdig(2023)的报告指出,公共 registry 中超过 60% 的镜像包含已知关键漏洞。

尽管安全工具不断涌现——包括镜像扫描器、运行时安全系统和准入控制器——但相关概念仍然碎片化,且缺乏对问题的统一形式化。大多数解决方案采用基于签名或启发式规则的方法,而没有对所需安全属性进行形式化建模。

因此,我们提出以下研究问题:

RQ1:如何以可验证、可度量的方式形式化容器环境中的安全属性?

RQ2:是否可以结合多层遥测,相较于单维方法显著提升攻击检测率?

RQ3:基于形式化策略的动态缓解机制对大规模集群的运行性能有何影响?

我们的主要贡献如下:

C1:将容器环境形式化建模为标记转移系统,并以数学方式表达隔离性与完整性属性。

C2:一种基于由 eBPF 遥测驱动的可变阶 Markov 链的概率检测机制。

C3:一种与 Kubernetes 集成的可扩展实现,并通过大规模实证评估展示显著的定量收益。

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

  1. 背景与相关工作

容器基于 Linux 内核的基本机制:namespaces $N = {pid, net, ipc, mnt, uts, user}$ 和施加资源限制的 cgroups $C$。形式化地,一个容器可定义为如下元组:

$$ \mathcal{K} = (P, N, C, I, \Pi) $$

其中 $P$ 表示进程集合,$I$ 表示基础镜像,$\Pi$ 表示所应用的策略集合(seccomp、AppArmor、SELinux)。

既有工作可分为三类:

(i) 静态镜像分析:Clair 和 Trivy 等工具分析依赖项和已知 CVE。

(ii) 运行时监控:Falco 使用基于系统调用的规则;Sysdig Secure 采用行为检测。

(iii) 准入策略与增强隔离:PodSecurityPolicies、OPA/Gatekeeper 和 gVisor。

从数学角度看,行为检测可建模为针对系统事件序列 $S = (s_1, s_2, …, s_n)$ 的分类问题。既有方法通常采用一阶 Markov 模型,假设:

$$ P(s_{i} | s_{i-1}) $$

然而,这类模型忽略了高阶依赖以及编排器的语义上下文。

常见局限包括:

我们的方案通过整合形式化建模与上下文化遥测,克服了这些局限。

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

我们假设对手具备以下能力:

(a) 通过利用被泄露的凭据部署恶意容器。
(b) 利用运行时或内核中的漏洞。
© 在 pod 之间进行横向移动。

我们将全局系统表示为有向图 $G = (V, E)$,其中 $V$ 表示容器,$E$ 表示通信连接。

我们将强隔离属性定义为:

$$ \forall v_i, v_j \in V, ; i \neq j \Rightarrow \neg \text{write}(v_i \rightarrow host \rightarrow v_j) $$

该问题在于检测事件序列 $S$,使得:

$$ P(S | \theta_{normal}) < \epsilon $$

其中 $\theta_{normal}$ 表示合法行为模型,$\epsilon$ 为自适应阈值。

  1. 所提方法

我们的架构由三个模块组成:(1) eBPF 收集器,(2) 概率建模引擎,(3) 缓解引擎。

Algorithm 1: 行为模型训练

Input: syscalls 序列 S
Output: 模型 M

1: 初始化 k-gram 计数器 C_k
2: 对于每个序列 S:
3:    对于 i = 1 到 |S|-k:
4:        C_k[S_i...S_{i+k}]++
5: 使用拉普拉斯平滑估计概率 P
6: 返回 M

Algorithm 2: 在线检测

Input: 事件 e_t, 模型 M
Output: 告警或正常

1: 更新窗口 W
2: 计算 P(W | M)
3: 如果 P < ε 则
4:    发出告警
5:    应用限制性策略

复杂度:训练为 $O(nk)$;在线检测每个事件为 $O(k)$。

  1. 实现

我们将收集器实现为与内核 5.15 绑定的 eBPF,事件通过 perf buffers 导出。后端使用 Apache Kafka 进行流式处理,并使用 Redis 进行临时存储。缓解模块与 Kubernetes Admission Controller 及 CRI-O 集成。

我们选择 eBPF 的原因是其相较于 ptrace(>15%)具有较低开销(<2%)。实验集群包含 48 个节点,每个节点具有 16 vCPU 和 64GB 内存。

  1. 实验评估

场景包括逃逸、特权提升和数据外泄攻击。指标包括:检测率(TPR)、误报率(FPR)和平均检测时间(MTTD)。

汇总结果:

在 T1611 攻击中,检测率达到 98,2%。相比之下,Falco 的 FPR 为 3,4%。

  1. 讨论

结果表明,可变阶建模能够捕获简单方法所忽略的上下文依赖。降低误报在高频变动的 CI/CD 环境中尤为重要。

局限性包括对初始训练阶段的依赖,以及可能通过低频慢速攻击实现规避。

  1. 结论与未来工作

我们提出了 CONTAINERSHIELD,一个用于容器安全的形式化与实证框架。我们证明了该方案在检测率提升和误报降低方面具有显著的定量收益,同时保持极低开销。

未来工作包括与跨集群联邦学习的集成,以及通过模型检验进行形式化验证。

  1. 参考文献

[1] P. Barham et al., “Xen and the Art of Virtualization,” SOSP, 2003.
[2] J. Merkel, “Docker: Lightweight Linux Containers,” Linux J., 2014.
[3] NIST SP 800-190, “Application Container Security Guide,” 2017.
[4] MITRE ATT&CK for Containers, 2023.
[5] A. Kivity et al., “kvm: the Linux Virtual Machine Monitor,” OLS, 2007.
[6] L. Torvalds, “Linux Kernel Documentation,” 2022.
[7] Sysdig, “2023 Cloud-Native Security Report.”
[8] Red Hat, “State of Kubernetes Security,” 2023.
[9] A. Madhavapeddy et al., “Unikernels,” ASPLOS, 2013.
[10] B. Burns et al., “Borg, Omega, and Kubernetes,” ACM Queue, 2016.
[11] CNCF, “Kubernetes Documentation,” 2024.
[12] Aqua Security, “Container Security Report,” 2023.
[13] D. Walsh, “SELinux and Containers,” Red Hat Summit, 2017.
[14] J. Corbet, “Namespaces in Operation,” LWN.net, 2013.
[15] S. Quinlan, “AppArmor,” USENIX, 2006.
[16] Falco Project Documentation, 2024.
[17] C. Kocher et al., “Spectre Attacks,” IEEE S&P, 2019.
[18] D. Borkmann, “eBPF and XDP,” Linux Plumbers, 2018.
[19] Google, “gVisor Documentation,” 2024.
[20] Open Policy Agent Documentation, 2024.