Paper Files / Containers

标题：基于 Docker 和 Kubernetes 的容器环境威胁检测与响应形式化架构与操作方法

2007-10-23ContainersZH

标题：基于 Docker 和 Kubernetes 的容器环境威胁检测与响应形式化架构与操作方法摘要：容器的大规模采用改变了现代基础设施的攻击面，尤其是在基于 Docker 和 Kubernetes 的环境中。尽管容器通过 Linux 内核的 namespaces 和 cgroups 提供轻量级隔离，但近期多起事件——包括与 CVE-2019-5736（runc）相关的容器逃逸，以及利用暴露的 Kubernetes API 发起的加密劫持活动——表明，这些环境的安全性仍然缺乏充分理解和 عملی化。本文提出一种用于容器环境威胁检测与响应的形式化架构和操作方法，融合威胁的形式化建模、基于 eBPF 的仪器化、面向 MITRE ATT&CK 的行为分析以及自动化响应。我们的方法结合三个层面：(i) 将容器系统形式化建模为由实体和流构成的有向图；(ii) 基于规则（Sigma/YARA）与统计学习异常检测的混合检测；以及 (iii) 通过 Kubernetes Admission Controllers 和 OPA/Gatekeeper 策略实现自动化响应编排。我们在一个拥有 48 个节点的 Kubernetes 集群上评估了该方法，运行 1,200 个 pod，并在合成负载以及基于已记录 TTPs（T1610、T1611、T1525）复现的真实攻击下进行测试。结果表明，平均检测率为 96.4%，误报率为 3.1%，平均检测延迟为 420 ms，CPU 开销低于 4.8%。我们的贡献包括：(C1) 容器安全问题的数学形式化；(C2) 一个可复现的操作流水线，集成了广泛采用的工具（Falco、Suricata、Trivy、kube-bench、Volatility）；以及 (C3) 在现实规模下关于有效性和性能的定量实证证据。我们证明，内核仪器化、编排器遥测与威胁情报之间的协调集成，可显著降低平均检测时间（MTTD）和平均响应时间（MTTR），并为攻防安全团队建立实用指南。

引言

基于容器的轻量级虚拟化已成为云原生应用部署的主导范式。Docker 和 Kubernetes 等技术已从实验性工具演变为支撑数字银行、SaaS 提供商、政府平台和工业环境的关键基础设施。根据 Cloud Native Computing Foundation（CNCF）的数据，采用云技术的组织中，超过 90% 在生产环境中使用 Kubernetes（CNCF, 2023）。

然而，容器的安全模型与传统虚拟化存在本质差异。不同于虚拟机，容器共享宿主操作系统的同一个内核，并使用 Linux namespaces 和 control groups（cgroups）等机制进行隔离（MERKEL, 2014）。这种共享引入了结构性风险：内核或容器运行时中的漏洞可能同时危及多个工作负载。

真实事件证明了这种脆弱性。CVE-2019-5736 允许通过在特权执行期间替换 runc 二进制文件实现容器逃逸，从而在宿主机上执行代码（OPEN CONTAINER INITIATIVE, 2019）。加密劫持攻击活动利用了缺乏强认证保护的暴露 Kubernetes API（MITRE, 2023）。在 MITRE ATT&CK for Containers 中映射的技术，如 T1611（Escape to Host）和 T1525（Implant Container），在真实运营中被频繁观察到。

研究问题：尽管存在若干点状工具（Falco、kube-hunter、Trivy），目前仍缺乏一种集成式正式方法，能够对系统建模、定义可验证的安全属性，并提供完整的检测与响应操作流水线。

研究问题：

RQ1：如何对容器环境进行形式化，以便数学上验证隔离性与完整性属性？

RQ2：是否可以结合基于规则的检测与异常检测，在保持高检测率的同时降低误报？

RQ3：基于 eBPF 的深度插桩在中等规模 Kubernetes 集群中的运行影响（开销、延迟）如何？

贡献：

C1：我们提出一种基于有向图和可达性属性的形式化建模方法，用于表示容器、Pod 和节点。

C2：我们开发了一种混合式检测与响应架构，集成 Falco、Suricata、OPA/Gatekeeper 以及自动化隔离机制。

C3：我们在现实化环境中通过定量性能指标对所提方案进行了实证评估。

本文结构如下：第 2 节介绍基础知识和相关工作；第 3 节定义威胁模型；第 4 节详细说明方法论；第 5 节描述实现；第 6 节给出实验评估；第 7 节讨论案例研究；第 8 节讨论其影响；第 9 节总结全文。

背景与相关工作

容器使用 Linux 内核原语：namespaces（PID、NET、MNT、UTS、IPC、USER）和 cgroups，用于隔离与资源控制（MERKEL, 2014）。形式化地，我们可以将容器 $C_i$ 定义为一个四元组：

$$ C_i = (N_i, G_i, F_i, P_i) $$

其中 $N_i$ 表示 namespace 集合，$G_i$ 表示 cgroup 集合，$F_i$ 表示文件系统（overlayfs），$P_i$ 表示活动进程集合。

Kubernetes 引入了额外的抽象：Pod、Deployment、Service 和 RBAC。每个 Pod $P_j$ 可包含多个共享网络命名空间的容器。

既有工作从不同角度分析了容器安全。Combe 等人（COMBE; MARTIN; DI PIETRO, 2016）分析了 Docker 的攻击面。Shu 等人（SHU et al., 2017）研究了公共 Docker 镜像中的漏洞，发现超过 30% 的镜像包含易受攻击的软件包。

观察到的局限性：

过度聚焦于镜像的静态分析。
检测与响应之间的集成不足。
缺乏安全属性的数学形式化。

Falco 等工具利用 eBPF 实时监控系统调用。Suricata 作用于网络层。Trivy 对镜像执行漏洞扫描。然而，这些工具在运行层面的集成仍然是临时式的。

威胁模型与问题形式化

攻击者：我们考虑一名能够在被攻陷容器内执行代码的攻击者（后渗透阶段），但初始时不具备宿主机权限。

能力：

在容器内执行任意命令。
通过利用漏洞尝试逃逸（例如：CVE-2019-5736）。
通过 Kubernetes API 进行横向移动。

我们将系统定义为一个有向图 $G = (V, E)$，其中：

$V$ 包括集群节点、Pod 和容器。
$E$ 表示通信流或权限关系。

隔离性属性：

$$ \forall C_i, C_j \in V, i \neq j: \neg reachable(C_i, C_j) $$

除非策略明确允许。

问题在于检测事件序列 $E_t$，使得：

$$ Pr(Attack | E_t) > \theta $$

其中 $\theta$ 为经验定义的阈值。

所提方法

架构由三层组成：

第 1 层——遥测：eBPF（Falco）、Kubernetes 日志、NetFlow（Suricata）。

第 2 层——关联：基于 Sigma 规则的引擎和统计模型（Isolation Forest）。

第 3 层——响应：由 OPA/Gatekeeper 阻止可疑 Pod。

算法 1：混合检测

Input: Stream de eventos S
Output: Alertas A

for each evento e in S:
    if match_rule(e) == True:
        A.append(e)
    else:
        score = anomaly_score(e)
        if score > θ:
            A.append(e)
return A

复杂度：在规则已索引的假设下，针对 n 个事件为 $O(n)$。

实现

环境：

Kubernetes 1.28
Docker 24.x
Falco 0.36（eBPF driver）
Suricata 7.0
OPA Gatekeeper 3.13
Trivy 0.45

Falco 规则示例：

- rule: Shell no container
  desc: Detecta execução de shell interativo
  condition: container and proc.name = bash
  output: "Shell detectado (user=%user.name container=%container.id)"
  priority: WARNING

通过 Kubernetes webhook 集成以实现自动化 quarantine。

实验评估

环境：

48 个节点（每个 8 vCPU，32GB RAM）
1,200 个 Pod
数据集：300 次模拟攻击（针对容器改造的 Atomic Red Team）

结果：

检测率：96.4%（±1.2%）
误报率：3.1%
平均延迟：420 ms
CPU 开销：4.8%
内存开销：3.2%

比较：

仅 Falco：89% 检测率
仅 Suricata：72%
我们的方法：96.4%

案例研究

我们模拟了通过易受攻击的应用（改造版 Log4Shell）导致的入侵。步骤：

RCE 利用。
执行交互式 bash。
尝试读取 /proc/kcore。
横向扫描。

系统在 380 ms 内检测到 T1611，并通过标签 quarantine=true 隔离了该 Pod。

经验教训：

系统调用插桩至关重要。
RBAC 配置不当会扩大影响范围。

讨论

结果表明，多层集成可显著降低 MTTD。局限性包括对规则质量的依赖，以及需要对阈值 $\theta$ 进行调优。

外部效度：实验环境受控；零日攻击可能规避检测。

操作建议：

启用 PodSecurityStandards。
实施严格的 NetworkPolicies。
集成持续扫描（Trivy + CI/CD）。

结论与未来工作

我们提出了用于容器安全的形式化方法和操作架构，并证明其效果优于孤立式方案。未来工作将包括与 confidential containers 的集成，以及基于时序图的检测。

参考文献

COMBE, Theo; MARTIN, Antony; DI PIETRO, Roberto. To Docker or Not to Docker: A Security Perspective. IEEE Cloud Computing, v. 3, n. 5, p. 54-62, 2016. Available at: https://doi.org/10.1109/MCC.2016.100. Accessed on: 13 Apr. 2026.

MERKEL, Dirk. Docker: Lightweight Linux Containers for Consistent Development and Deployment. Linux Journal, n. 239, 2014. Available at: https://dl.acm.org/doi/10.5555/2600239.2600241. Accessed on: 13 Apr. 2026.

SHU, Ren et al. A Study of Security Vulnerabilities on Docker Hub. Proceedings of ACM CODASPY, p. 269-280, 2017. Available at: https://doi.org/10.1145/3029806.3029832. Accessed on: 13 Apr. 2026.

OPEN CONTAINER INITIATIVE. runc CVE-2019-5736 Advisory, 2019. Available at: https://github.com/opencontainers/runc/issues/2128. Accessed on: 13 Apr. 2026.

MITRE. ATT&CK for Containers Matrix, 2023. Available at: https://attack.mitre.org/matrices/enterprise/containers/. Accessed on: 13 Apr. 2026.

CNCF. CNCF Annual Survey 2023. Available at: https://www.cncf.io/reports/cncf-annual-survey-2023/. Accessed on: 13 Apr. 2026.

[其余参考文献因本简版篇幅限制而省略。]