该论文研究如何保护容器化工作负载(如 Docker 容器与 Kubernetes Pod)免受中间人(Man-in-the-Middle, MitM)攻击。作者首先指出一个常被忽视的事实：容器化环境虽然提供隔离与编排便利，但其内部工作负载仍然暴露于与非容器环境相同的攻击面，包括钓鱼、应用层漏洞利用以及网络入侵；而容器具有动态调度、生命周期短、东西向流量密集、配置易漂移等特性，使传统边界防护与静态网络策略难以覆盖通信链路上的窃听、篡改与会话劫持风险。方法上，研究采用基于 PRISMA 指南的系统性综述(Systematic Review)，对同一研究主题的既有证据进行检索、筛选与汇总，提取出可复用的成功要素(success factors)；在综述基础上开展设计型研究(design-and-creation)，提出一个面向容器化操作系统的安全框架。该框架的核心包括三部分：一是用于描述通信行为与密码原语的概念模型(conceptual model)，使安全属性可被形式化刻画；二是借助 AnBxJ Java 安全库来实现与验证通信安全；三是部署工作在 OSI 模型第 7 层(应用层)的容器防火墙，将访问控制与检查从网络层提升到应用层，并结合零信任(Zero Trust)架构原则，对通信双方进行持续的身份确认与完整性校验。研究围绕一个核心问题展开：如何有效保护容器化操作系统免受 MitM 攻击。验证部分在一个容器化操作系统场景中成功实现了该安全机制，并识别出实现过程中的成功因素。论文的价值主张是帮助从业者系统化容器安全实践，并为 Docker 与 Kubernetes 部署提供可落地的零信任参考架构。需注意，本文属于综述加设计型研究，重点在方法论与架构层面，摘要中并未给出量化实验结果、性能开销数据或具体攻击面测绘结论，因此结论的可迁移性仍需结合完整论文与实测验证。

本文是首项针对 Kubernetes 控制平面中第三方插件与应用程序权限过大的系统性安全研究。Kubernetes 作为当前主流的容器编排系统，其控制平面通常会运行各类第三方插件（如监控、日志、网络、存储等组件）来辅助集群管理，这些第三方应用往往被授予较高权限。作者指出，这些第三方应用的安全状况此前未被系统性地审视过，而一旦其中一个应用被攻破或存在恶意行为，攻击者可能借助其过度授权横向移动并最终控制整个集群。研究围绕“第三方应用权限过大”这一核心问题展开，分析了相关权限模型、Kubernetes 基于角色的访问控制（RBAC）机制以及第三方应用常见的权限申请模式，并提出了攻击路径的威胁建模方法。论文的主要贡献包括：首次系统性地梳理了 Kubernetes 第三方应用的安全风险面，设计了针对该风险的攻击链分析方法，并通过实验验证了在真实集群环境中利用过度权限可实现集群级接管。该工作为云原生安全领域提供了新颖的研究视角，也为 Kubernetes 集群管理员和插件开发者提供了安全加固依据。适合云原生安全研究人员、Kubernetes 运维及安全工程师阅读。

本文提出 KubeCap，一个面向 Kubernetes 工作负载的最小权限能力缩减框架。研究背景是：Kubernetes 作为最流行的容器编排平台，允许开发者通过 manifest 文件管理 Linux capabilities，但实践中开发者常依赖默认设置或粗粒度的安全上下文，违反最小权限原则，扩大了容器化工作负载的攻击面。现有研究要么只检测 Kubernetes manifest 中的脆弱模式，要么只为独立 Linux 程序推断所需能力，均未直接解决 Kubernetes 环境下的能力最小化问题。作者首先对三个开源数据集进行实证研究，发现 74.67% 的项目缺乏能力配置，表明该问题普遍存在。KubeCap 的工作流程包括：将部署规格转换为确定性 manifest、定位容器入口点、执行可达性引导的系统调用分析，并利用 LLM 辅助规则推断从 Linux 内核代码中提取 syscall-参数-能力 的关联关系。基于这些结果，KubeCap 为每个工作负载推断所需的最小能力集合，并自动生成修复后的 manifest。在 10 个基于 Go 的代表性 Kubernetes 项目上评估，平均能力缩减率达 54.97%，优于快速类型分析和类层次分析基线，且保持了实用的分析成本。实验证明 KubeCap 能有效在 Kubernetes 中实施最小权限原则。

本文旨在研究在 Kubernetes 集群安全修复中，为大型语言模型（LLM）提供运行时拓扑上下文是否能够显著提升生成补丁的正确性。研究背景是：云原生生态中 Kubernetes 成为容器化工作负载编排的核心，已有工作提出利用 LLM 自动化生成安全配置补丁，以响应 Kubernetes 安全态势管理（KSPM）平台的发现，而无需人工介入。然而，现有系统通常在提示模型时仅孤立地呈现每个安全发现，不结合实时服务调用图，默认模型具备通用加固知识即可生成正确补丁。这一假设在补丁需要保留模型不可见的运行时服务依赖时失效：一个看似合规的修复可能由于破坏服务间调用关系，导致下游调用者崩溃或静默切断跨集群的调用边，造成功能损坏。但将实时集群上下文纳入补丁生成是否能提升正确性，此前缺乏多依赖类别的受控量化评估。为此，作者提出了 KuTIE（Kubernetes Topology Intelligence Engine），它从 Istio 调用边、Trivy KSPM 发现以及工作负载读取的 ServiceAccount 绑定中构建实时集群上下文，并将这些上下文作为 LLM 补丁生成的条件输入。作者构建了 VulnCare 评估环境：一个包含 36 个部署、4 个命名空间的医疗类集群，在其中注入 31 个跨 7 个依赖类别的可修复发现，每个发现都根据集群真实情况标注了拓扑依赖程度。在 248 次试验中，拓扑上下文将拓扑相关补丁的正确率从 11.1% 提升到 78.0%（提升幅度 Δ=0.669），且这一提升在每一种测试模型和 7 个类别中的 6 个中均成立（例如凭证与网络策略类 Δ=0.95，RBAC 类 Δ=0.31）；而一个与拓扑无关的对照组没有表现出类似提升（Δ=0.0），从而排除了通用提示词增强的干扰。实验结论表明，提供实时服务调用图及其暴露的 ServiceAccount 绑定，能显著改善拓扑相关安全发现的自动修复质量，远优于仅依赖扫描器上下文的做法。该研究为云原生环境下 LLM 驱动的安全修复提供了新的设计方向，具有量化评估显著性。

Kubernetes 作为主流的容器编排系统，拥有庞大的第三方应用生态。这些应用通过 RBAC 机制访问集群资源，但往往被授予过度权限，造成安全隐患。已有研究提出了过度权限攻击，但假设攻击者已通过容器逃逸攻陷工作节点，现实中难以实现。本文提出一种新的过度权限攻击模型，攻击者只需攻陷一个 Pod（难度低于攻陷节点），即可利用某些过度权限接管工作节点，或破坏其他 Pod 的可用性与数据机密性。针对第三方应用过度权限难以检测的问题，作者提出 EPScan 方法，自动检测可被利用的过度权限。EPScan 创新地采用面向 Pod 的程序分析技术，精准识别每个 Pod 中程序的资源访问行为，并与配置文件中请求的权限进行比较，最终报告可被滥用于执行过度权限攻击的权限。作者在来自 CNCF 项目的 108 个第三方应用上测试 EPScan，发现了 50 个应用中 106 个 Pod 存在此前未知的可利用过度权限，检测精度达 94.6%，并获得了 9 个 CVE 编号。该方法为 Kubernetes 安全运维提供了有效检测手段，适合云原生安全研究人员、集群管理员和 DevOps 工程师阅读。

本研究针对Kubernetes（K8s）在微服务架构中作为容器编排标准所面临的安全配置一致性问题，系统比较了八种常用的Kubernetes加固指南，并基于最佳实践建立了包含79项配置建议的基准。通过对十种流行的静态配置扫描工具的结构化实证评估，发现不同加固指南和扫描器在配置问题覆盖范围上存在显著差异，且不同工具对配置问题的评分和排序方式不一致。研究结果强调了需要更标准化、透明和一致的Kubernetes配置问题风险评估方法。对于安全团队而言，该研究揭示了当前工具和标准之间的鸿沟，有助于选择更合适的扫描策略，并推动行业统一基准的形成。

随着LLM即服务等机密云工作负载的兴起，用户数据必须在可信且未被篡改的环境中处理，这需要密码学证明。现有的解决方案，特别是Confidential Containers (CoCo)，强制采用严格的“每个Pod一个虚拟机”模型，仅证明客户操作系统栈，而忽略了容器级别的身份验证，并且每个虚拟机带来巨大的资源开销。本文提出了dstack-capsule，一个基于Kubernetes的平台，在Intel TDX上实现了Pod级别的远程证明。其核心思想是两层证明架构：静态平台测量通过不可逆的特权熔断机制冻结在RTMR[3]中，而动态Pod身份（pod_uid、pod_spec_hash、workload_id）嵌入在TDX Quote的report_data字段中，每次请求由硬件签名。dstack-capsule引入了以下主要贡献：(1) Pod级别证明协议，将Pod规范摘要绑定到硬件签名的Quote上；(2) 特权熔断机制，将节点从设置模式原子性地转换到安全模式；(3) 多层沙箱，涵盖存储、运行时、准入、API和网络隔离层；(4) 基于Kubernetes 1.32、Intel TDX和Sysbox的完整开源实现。实验评估了安全属性、证明正确性和性能特征，表明dstack-capsule实现了Pod粒度的验证，而无需每个虚拟机隔离的资源开销。该工作适合对机密计算、Kubernetes安全以及硬件辅助信任执行环境感兴趣的安全工程师和研究人员。

本文首次系统性地研究了Kubernetes Operator中的跨命名空间引用漏洞。Kubernetes Operator是用于自动化管理应用生命周期的工具，它们通常需要高权限并跨多个命名空间操作，这引入了新的安全风险。Kubernetes通过命名空间隔离来限制用户访问，但Operator可能因为声明的资源范围与实际逻辑范围不匹配，导致命名空间隔离被绕过。攻击者利用这种漏洞，即使只在一个授权命名空间内拥有有限权限，也能通过Operator影响其他未授权命名空间，实现权限提升等危害。作者提出了跨命名空间引用漏洞的两种攻击策略，并通过大规模测量发现超过14%的公开Operator存在潜在漏洞。研究结果已报告给相关开发者，获得8个确认和7个CVE（涉及Red Hat、NVIDIA等厂商）。作者开源了静态分析套件并提出了缓解措施，以增强Kubernetes Operator的安全性。本文适合Kubernetes安全研究人员、云原生安全工程师、Operator开发者以及Kubernetes管理员阅读。