Kubernetes 安全模型是为一个以边界为主要防御的世界而设计的。防火墙守护着城堡城墙，内部的一切都相对可信。像 Istio 和 Linkerd 这样的服务网格本应通过服务间添加相互 TLS 加密和基于身份的访问控制来改善这一点。然而，它们无意中创造了攻击者遇到的最高效的横向移动基础设施。
在 2026 年，最复杂的 Kubernetes 攻击不再费劲地通过蛮力突破边界。它们攻陷单个 Pod——通常通过有漏洞的依赖项或配置错误的容器镜像——然后几乎毫无阻碍地穿过服务网格，利用那些本应为安全提供保障的信任关系。
服务网格横向移动攻击剖析
这种攻击模式以其简单性而显得优雅。攻击者攻陷一个低权限的 Pod——可能是一个带有未修补依赖项的日志 sidecar，或是在生产命名空间中意外暴露的开发工具。在传统网络中，这个立足点的价值有限。被攻陷的 Pod 需要发现其他服务、建立连接，并在每一步绕过网络级访问控制。
在服务网格环境中，被攻陷的 Pod 继承了更有价值的东西：一个有效的 mTLS 身份。网格的 sidecar 代理——在 Istio 中是 Envoy，Linkerd 中是 proxy-rs，或类似组件——自动为 Pod 提供一个加密证书，将其标识为网格的合法成员。Pod 与其他服务建立的每个连接都会被网格控制平面自动加密、认证和授权。
攻击者不需要破解任何密码或窃取任何令牌。网格基础设施透明地处理身份验证。如果被攻陷 Pod 的服务账户具有允许与其他服务通信的授权策略——在大多数实际部署中，这些策略比应有的要宽松得多——攻击者就可以通过有效、加密、完全认证的连接到达那些服务，这种连接与合法流量看起来完全相同。
这是根本的悖论：mTLS 认证的是 Pod 身份，而非意图。从网格的角度来看，拥有有效证书的被攻陷 Pod 与健康的 Pod 无法区分。保护合法流量的加密同样保护恶意横向移动，使其免受网络级检测工具的发现。
信任关系利用链
服务网格创建隐式信任图，攻击者会系统地映射和利用这些信任图。在典型的微服务架构中，服务 A 调用服务 B，服务 B 调用服务 C，服务 C 访问数据库。网格授权策略允许这些连接。攻破服务 A 的攻击者可以到达服务 B。从服务 B 的上下文，他们可以到达服务 C。从服务 C，他们可以访问数据库。每个跳转都是完全认证和加密的。
当与服务账户令牌盗窃相结合时，攻击变得特别具有破坏性。Kubernetes 服务账户令牌默认挂载在每个 pod 中，可用于查询 Kubernetes API 服务器以获取服务发现信息。攻击者可以枚举服务，识别高价值目标——数据库、密钥存储、认证服务——并使用网格自身的服务发现机制规划其横向移动路径。
AI 驱动的攻击工具使这一过程更快且更自动化。进攻性安全框架现在集成了机器学习模型，这些模型可以分析网格流量模式，识别到高价值目标的最短路径，并执行与合法流量模式足够相似的横向移动序列，从而规避行为检测。从初始 pod 被攻破到访问数据库的时间已从数小时缩短到数分钟。
供应链投毒：入口向量
enable 网格横向移动的初始入侵越来越多地源自供应链攻击。恶意容器镜像、被攻破的 Helm 图表和被投毒的依赖库提供了初始立足点。作为容器构建中的传递性依赖包含的特洛伊化 npm 包或 Python 库可以建立反向 shell 或注入能在容器重启后存活 web shell。
容器生态系统依赖于由未知第三方维护的基础镜像，这创造了巨大的攻击面。单个被攻破的基础镜像可以在整个组织中传播到数百个派生镜像。当这些容器部署到服务网格环境中时，每个容器都成为通过网格信任基础设施进行横向移动的潜在入口点。
真正有效的防御策略
防御服务网格横向移动需要放弃网格级认证等于安全的假设。几种具体策略已在生产环境中被证明是有效的。
采用显式”全部拒绝”默认策略的微分段是最具影响力的单一改变。组织不应允许所有网格流量并选择性拒绝，而应默认拒绝所有服务间通信，仅明确允许业务逻辑所需的连接。Istio 的 AuthorizationPolicy 和 Cilium 的网络策略支持此模型，但实施它需要彻底理解合法的服务通信模式——像 Kiali 这样的服务网格可观测性工具可以帮助映射这些模式。
在 Pod 级别的运行时安全监控检测到网格级别身份验证无法发现的行为异常。Falco、Tetragon 和 KubeArmor 等工具监控容器内的系统调用、文件访问模式和网络连接。当被入侵的 Pod 开始发起它从未进行过的 API 调用，或访问超出其正常模式的文件时，运行时安全工具可以检测并发出警报，无论网格是否认为该连接已通过身份验证。
限制 Pod 出站流量仅到其需要特定服务的网络策略——不仅仅是网格允许的服务——在网格下方增加了一层防御。Cilium 基于 eBPF 的网络策略在内核级别运行，实施的限制即使被入侵，网格边车代理也无法覆盖。
使用绑定且有时间限制的令牌进行服务账户令牌投影，取代了攻击者滥用的默认长期有效令牌。Kubernetes 1.24 及更高版本默认支持绑定的服务账户令牌，但许多集群仍挂载传统令牌以保持向后兼容性。
令人不安的真相
服务网格仍然是宝贵的基础设施。双向 TLS、流量管理、可观测性和弹性功能证明了其操作复杂性是合理的。但它们提供的安全模型是必要条件而非充分条件。部署服务网格并认为其服务间通信已得到安全保护的组织，恰恰创造了现代攻击者旨在利用的环境。
2026 年 Kubernetes 威胁态势需要纵深防御：网格级身份验证加上微分段加上运行时行为监控加上供应链验证加上最小权限服务账户。每一层都解决不同的故障模式。共同作用下，它们使得在网格中的横向移动变得困难、可检测且可控制。单独来看，任何一层都不够。游弋在您服务网格中的攻击者正指望您不知道这一点。