本文旨在研究在 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管理员阅读。