深入解析 Kubernetes API：非标准 Pod 与容器监控局限与安全实践

Kubernetes 的普及率不断提高，这表明它在持续集成（CI）和持续交付（CD）管道中带来了显著的优势，例如更快的构建和部署时间。根据云原生计算基金会（CNCF）的数据，96%的组织正在使用或考虑使用 Kubernetes。此外，2022 年第三季度主要云提供商收入增长了 20%，进一步证明 Kubernetes 的采用率仍在持续上升。

然而，随着 Pod 和容器在组织生态系统中的普及，开发团队和安全团队需要意识到 Kubernetes API 在监控和列出特定类型的 Pod 和容器时存在一定的局限性。这些限制可能源于设计考量、控制平面配置，或对相关细节的了解不足。同时，攻击者可能会利用这些局限性实施未经授权的访问、权限提升或其他恶意活动，从而逃避检测。

标准 Pod 的特性与局限性

在 Kubernetes 中，Pod 是封装一个或多个容器的逻辑单元，也是 Kubernetes 可直接管理的最小对象。Pod 可以通过 Kubernetes API 创建和定义，通常使用 kubectl get pods 或 kubectl describe 命令查询其状态。Pod 中的容器基于镜像定义，即使两个 Pod 使用相同的镜像，其资源配置、文件系统挂载及权限设置等属性可能不同。

尽管标准 Pod 是 Kubernetes API 的核心管理对象，但并非所有 Pod 都由 API 管理。接下来，我们将探讨一些非标准 Pod 的类型及其特性。

静态 Pod

静态 Pod 是由 kubelet 而非 Kubernetes API 管理的 Pod，通常用于引导 Kubernetes 控制平面及其内部服务（如 API 服务器）。由于其管理方式的特殊性，静态 Pod 无法引用其他 Kubernetes 对象（如 Secret、ConfigMap 和 ServiceAccount）。

创建静态 Pod

要创建静态 Pod，需配置 kubelet 以接受静态 Pod 清单。可以通过以下方式实现：

• 在 kubelet 配置文件中指定 staticPodPath 或 staticPodURL。
• 使用命令行参数 --pod-manifest-path 或 --manifest-url。

例如，在 Google Kubernetes Engine（GKE）中，默认 kubelet 配置文件路径为 /home/kubernetes/kubelet-config.[yaml](https://www.explinks.com/wiki/ymal/)，其监控的静态 Pod 清单路径为 /etc/kubernetes/manifests。

静态 Pod 的发现

由于 Kubernetes API 并不直接管理静态 Pod，因此无法通过 API 查询其状态。然而，kubelet 可以通过创建镜像 Pod（Mirror Pod）将静态 Pod 的信息报告给控制平面。

镜像 Pod

镜像 Pod 是由 kubelet 生成的对象，用于在控制平面上表示静态 Pod。要启用镜像 Pod，需配置 kubelet 并授权其在控制平面上创建这些对象。然而，根据控制平面的设置，镜像 Pod 可能未启用，这使得依赖 API 的监控工具无法发现这些 Pod。

静态 Pod 与镜像 Pod 的安全隐患

由于静态 Pod 由 kubelet 管理，攻击者若获得节点访问权限，可能通过修改静态 Pod 清单路径或 URL 创建特权静态 Pod，从而实现主机逃逸攻击。此外，攻击者还可能利用静态 Pod 实现隐蔽的持久性，例如在现有静态 Pod 中添加恶意容器。

初始化容器

初始化容器（Init Container）用于在主应用容器启动前执行初始化任务，例如下载配置文件、准备数据库或延迟启动应用容器。Init 容器与标准容器不同，其资源请求和限制是独立设置的。

创建与发现初始化容器

Init 容器通过 Pod 规范中的 spec.initContainers 字段定义，其状态可通过查询 Pod 的状态字段查看。尽管 Init 容器通常被忽视，但其在引导和设置阶段的重要性使其成为潜在的攻击目标。

Pod Infra 容器（暂停容器）

Pod Infra 容器（Pause Container）是 Kubernetes 中的占位容器，用于为 Pod 分配系统资源（如 cgroups 和命名空间）。该容器由 kubelet 管理，Kubernetes API 无法直接感知其存在。

暂停容器的安全风险

由于 API 无法监控暂停容器，攻击者可能通过替换暂停容器镜像实现隐蔽的持久性。例如，攻击者可以修改 kubelet 配置文件中的 podInfraContainerImage 参数，将其替换为恶意镜像。

短暂容器

短暂容器（Ephemeral Container）主要用于调试目的，可动态添加到运行中的 Pod 中。尽管短暂容器没有明确的资源分配保证，但其灵活性使其成为调试和分析的有力工具。

创建与发现短暂容器

短暂容器可通过 kubectl debug 命令创建，并通过 Pod 规范中的 spec.ephemeralContainers 字段进行识别。

总结

本文探讨了 Kubernetes 中的各种 Pod 和容器类型，包括标准 Pod、静态 Pod、镜像 Pod、初始化容器、暂停容器和短暂容器。我们分析了 Kubernetes API 在监控这些对象时的局限性，并指出了潜在的安全风险。

尽管 Kubernetes API 是强大的监控工具，但其局限性表明需要结合其他监控解决方案（如工作负载运行时代理）以全面保护 Kubernetes 环境。对于安全团队和开发团队而言，理解这些非标准 Pod 和容器的特性及其潜在风险，对于提升 Kubernetes 环境的安全性至关重要。

原文链接: https://www.wiz.io/blog/kubernetes-api-limitations-in-finding-non-standard-pods-and-containers