Kubernetes 初始访问向量第 2 部分 数据平面

Kubernetes Initial Access Vectors Part 2 Data Plane

这是我们两篇博客系列的第二部分，我们在其中探讨了进入 Kubernetes 环境的各种初始访问向量，分析了相关的攻击角度，并阐明了相关风险。

分类法

在第一篇博客中，我们介绍了初始访问向量的分类法，并讨论了控制平面访问。在这一部分中，我们重点讨论数据平面访问。我们将介绍从集群上运行的应用程序中产生的可能的初始访问向量，讨论容器镜像的相关问题（它们的来源和潜在的逃逸场景），并以执行即服务的工作负载类型作为结尾。

应用程序

Kubernetes 集群旨在运行工作负载。自然，这些工作负载通过实现业务逻辑来执行某些操作。每个工作负载都可能存在导致远程代码执行（RCE）的关键漏洞。要使漏洞可被利用，它必须被外部用户暴露和可达——无论是直接（例如，前端 pod 中的 RCE）还是间接（例如，配置错误导致 SQL 数据库 pod 中的 RCE，通过前端 pod 访问）。由于应用程序安全性超出了本文的范围，我们在此重点讨论如何在初始访问后遏制攻击者。在这种情况下，恶意行为者会发现自己处于一个易受攻击的 pod 的执行上下文中，如下图所示：

从这一点开始，攻击者有两个主要向量可用：（1）滥用与该 pod 的服务账户（SA）相关的 Kubernetes RBAC 权限和/或（2）滥用当前容器或邻近 pod 容器内的系统权限以逃逸到主机并横向移动。设计了几种安全边界来防止这些横向移动和权限升级场景，例如 Kubernetes 命名空间（RBAC 分离）、Pod 安全标准（限制 pod 系统能力）、网络策略和专用 Kubernetes 节点调度。攻击者的成功取决于这些安全控制的有效性。在我们的2023 年 Kubernetes 安全报告中，我们强调了一旦攻击者获得初始访问权限后横向移动机会的丰富性。Wiz 漏洞研究团队发现的涉及 Kubernetes 基础设施的安全漏洞阵列证明了这一点。

我们强烈建议在集群内使用多种安全边界，特别是：

• 将前端和外部暴露的 pod 分离到一个独立的命名空间，赋予它们的服务账户最小权限。

• 在命名空间级别应用适当的 Pod 安全标准（PSS）级别。根据敏感度级别拆分命名空间。

• 在管理 pod 中的漏洞时，优先处理那些公开暴露的 pod 和那些具有强大权限的 pod。

对于更严格的硬多租户，请考虑使用单独的 K8s 集群。查看 PEACH 云隔离框架以了解详细信息。

NodePort 服务

Kubernetes 提供了多种将工作负载暴露给外部用户的方法，其中负载均衡服务和应用程序网关是最受欢迎的。另一种不太常见的方法是通过 NodePort 服务暴露 pod。当集群操作员创建 NodePort 服务时，Kubernetes 会在工作节点上的默认范围 30000–32767 内打开一个静态端口。

NodePort 存在几个安全问题，主要是因为它通常不用于生产系统。因此，它的存在可能表明服务暴露是无意的。即使工作负载不存在，同一端口也会在集群中的所有节点上打开，不必要地增加了暴露。每个节点将端口代理到服务，使得直接访问成为可能。与负载均衡服务相比，细粒度的网络访问控制也更加有限。我们对 100 个使用 Kubernetes 设置的 Wiz 租户的随机样本进行的内部分析显示，大约 6% 的 NodePort 服务暴露在外部。

镜像和供应链

容器镜像呈现出一个不太明显但仍然危险的访问向量。如果攻击者控制了一个镜像并且集群 pod 拉取了它，从容器执行到本地节点管理员——甚至到集群管理员的路径可能很短。去年冬天发布的Leaky Vessels是强调不受信任镜像风险的最臭名昭著的漏洞之一。runc 库中的漏洞仅通过部署一个带有恶意镜像的 pod 就允许未经授权的主机级访问。

为了减轻这些风险：

• 为数据平面工作负载应用适当的 PSS 级别以防止容器逃逸。

• 使用命名空间作为防止横向移动的安全边界，将 RBAC 权限限制在命名空间范围内。

• 考虑在不需要特殊条件的 pod 上使用用户命名空间，根据我们之前的研究。此高级功能使得在主机上下文中根权限无效。

还需要知道的是，镜像是少数几个无法通过网络限制来缓解的向量之一，因为 pod 需要从容器注册表下载镜像。恶意镜像强调了拥有高质量软件和与受信任合作伙伴的强大托管链（SBOM 和签名）的重要性。这突显了在使用前验证容器镜像的重要性。镜像安全的两种策略是：

1. 维护一个带有漏洞和来源检查的本地（镜像）容器注册表。

2. 通过准入控制器（AC）逻辑实现镜像签名验证，以确保仅部署签名的受信任镜像。

Wiz 最近使得在 Kubernetes 集群中确保安全的软件供应链变得极其容易。传统的镜像验证方法是通过数字签名建立镜像信任。这确保了部署的镜像来自受信任的来源（使用公钥在部署时验证签名的镜像）。

Wiz 通过 Wiz 镜像信任 将其提升到一个新的水平，不仅建立信任，还将安全策略紧密绑定到每个部署的镜像，从而确保镜像符合组织的安全合规性：在镜像被拉取之前和任何时候扫描 CVE、恶意软件和嵌入的秘密——轻松导航回到与部署镜像相关的 CI/CD 扫描和扫描策略。这是在不必处理密钥管理的情况下完成的，而密钥管理通常是与签名和验证镜像相关的最具挑战性的操作方面之一。

执行即服务

一个经常被低估的初始访问向量是执行即服务，其中服务供应商为服务用户提供执行能力。例如，运行外部 AI 模型的能力相当于执行任意代码。由于 Kubernetes 是一种非常方便的技术，AI 供应商越来越多地利用 K8s pod 和容器来运行模型。因此，供应商必须依赖 K8s 安全分离控制，而正如我们之前所见，这些控制很难做到正确。

Wiz 漏洞研究团队在多个 AI 服务中发现了跨租户漏洞，例如HuggingFace 推理 API、Replicate 和 SAP AI Core。这些研究文章展示了与此类服务相关的主要风险——跨租户访问。下图显示了典型的妥协流程：

此外，这种攻击流程可以概括为影响任何依赖 Kubernetes 集群作为后端的执行即服务基础设施。提供此类服务的供应商必须在执行环境周围实施严格的安全控制。以下是需要考虑的关键措施：

• 每个执行 pod 一个命名空间（在可行的情况下）：将每个 pod 隔离到其自己的命名空间有助于遏制潜在的漏洞并限制攻击面。

• 执行 pod 的用户命名空间：此高级功能防止容器根权限转化为主机级别的根访问，增加了一层额外的安全性。

• 网络安全策略：实施细粒度的网络策略限制 pod 之间的通信，减少工作负载之间横向移动的可能性。

• 每个租户调度一个节点：将单个工作节点分配给不同的租户确保隔离，并防止共享基础设施环境中的跨租户威胁。

• 内核隔离和沙箱（例如，Kata 容器、gVisor、seccomp、AppArmor）：使用额外的内核级隔离和沙箱技术显著减少了容器逃逸的风险，并增强了系统级别的安全性。

最后，根据这些控制措施的实施效果，考虑切换到单独的虚拟机而不是依赖 Kubernetes 集群以实现更强的隔离。

云访问和 CI/CD

由于篇幅限制，我们无法在本文中涵盖云访问和 CI/CD 管道的广泛主题，但它们是 Kubernetes 安全中的关键领域。我们的 2023 年 Kubernetes 安全报告强调，绝大多数集群（超过 80%）是托管和运行在云中的，使它们成为更广泛的云基础设施的组成部分。这意味着集群操作员必须具备云 IAM（身份和访问管理）的可见性，以有效地管理大规模的集群访问。

云 IAM 是一个动态且复杂的领域，定期引入新的功能。我们预计这一领域将出现更多的权限升级漏洞，类似于我们在本系列早些时候详细介绍的一个。跟踪这些发展对于保持领先于新兴风险至关重要。

CI/CD 管道是现代软件开发过程的核心，另一个 Kubernetes 安全的重要向量。Kubernetes 集成到 CI/CD 工具链中，像 ArgoCD 和 Flux 这样的操作员自动化 K8s 资源在新旧集群中的部署。这些工具简化了操作，但它们也代表了一个重大的安全问题，因为 CI/CD 工作流通常对 Kubernetes 环境具有管理员级别的访问权限，可能为攻击者提供了获得集群初始立足点的途径。

结论

这篇博客是我们关于 Kubernetes 初始访问的两篇系列文章的结尾（阅读第一部分）。如所示，Kubernetes 是一个复杂的分布式系统，具有多个访问向量，任何一个——如果未加保护——都可能导致整个集群的妥协。我们希望这个分类法有助于系统化和优先考虑相关风险。