从容器逃逸到权限提升：一文拆解 k8s安全的核心风险

很多人都觉得以前做网络安全简单——其实也不算简单，只是相对可控。过去的安全体系虽然繁琐，但逻辑明确：

哪些用户权限危险
哪些通信需要加密
哪些入口需要重点关注

难是难，但至少方向是清楚的。

可当 Kubernetes 进入我们的技术栈，一切瞬间变得陌生。它不像传统系统，而更像一个全新的“世界观”：组件多、概念新、依赖链长。你甚至还没完全搞清楚它是怎么工作的，就已经要开始保护它了。

所以，Kubernetes 安全才会让人感觉像是在“摸着黑走路”。

在这篇技术博客里，我们不讲那些空洞的概念，也不试图一次性解决所有问题。我们会用一种研究式的方式来理解 Kubernetes 安全：

提出问题
针对问题寻找答案
在答案中归纳规律

这样做的目的不是让 Kubernetes 安全变轻松，而是让它变可掌控、可拆解、可理解。

准备好了，我们正式开始。

什么是 Kubernetes？

Kubernetes 是一个功能强大的容器编排平台，用于高效部署、扩缩容以及管理应用。它通过自动化容器应用的生命周期，让开发者可以更专注于业务，而不用操心底层基础设施。

Kubernetes 本质上是一个完整的平台，一个管理多种资源的运行环境。 在这篇文章中，我们重点讨论两个与安全高度相关的资源：

• Roles（角色）
• Pods（Pod）

Roles（角色）

角色定义了权限。通过 Role 和 RoleBinding，Kubernetes 实现了细粒度的访问控制，确保用户或 ServiceAccount 只能执行被允许的动作。

一旦拥有高权限角色的用户或服务账号被攻破，攻击者就能执行超出授权的操作，从而危害整个集群。

Pods（Pod）

Pod 是 Kubernetes 中最基础的执行单元。一个 Pod 里可以包含一个或多个容器，它们共享同一网络和存储资源。这种封装方式让组件协作更高效，但也意味着：一旦 Pod 被攻陷，攻击者就能借助 Pod 的网络与权限，在集群内部横向移动，甚至攻破整个集群。

为什么 Kubernetes 如此重要？

根据 CNCF 2022 年年度报告：

容器使用者面临的前两大挑战之一就是安全，其中 40% 的受访者认为安全是他们最大的痛点。

而 CNCF 2023 报告 显示：

84% 的受访者正在使用或评估 Kubernetes，安全依然是约 40% 用户的核心挑战。

也就是说：Kubernetes 越普及，安全挑战越突出。

为什么企业仍然选择 Kubernetes？ 因为它支持大规模微服务架构，具备模块化、高可用与可扩展特性，是现代云原生体系的核心。

Kubernetes 的攻击面

系统复杂度越高，攻击面越大。Kubernetes 就是一个非常复杂的系统。在攻击者眼里，攻破 Kubernetes 通常包括两个方向：

攻击容器
在 Kubernetes 集群内部推进攻击路径

1. 攻击容器：Container Escape（容器逃逸）

当攻击者利用内核漏洞、容器运行时漏洞或应用漏洞突破容器沙箱，进入宿主机，就发生“容器逃逸”。

在单机上被逃逸已经很严重， 但在 Kubernetes 节点上被逃逸？ 那基本就是“宣告集群无法工作”的信号。

2. 利用 Kubernetes 本身：Lateral Movement（横向移动）

攻击者一旦进入一个 Pod，就可能通过以下方式移动到其他 Pod 或组件：

滥用 Role/ClusterRole 的权限
错误配置的 NetworkPolicy
Kubernetes 组件漏洞

容器逃逸难度大，但如果攻击者能在集群内部横向移动、访问更多服务，就能找到更容易突破的点，最终获取关键权限。

Privilege Escalation（权限提升）

通过漏洞或配置错误，攻击者可能最终获取控制平面权限，接管整个集群。MITRE ATT&CK 和 Microsoft 也都将 Kubernetes 视为一个独特的“攻击生态”，需要从容器运行时、控制平面、基础设施等多个层面进行整体防护。

焦点：应用访问 Token（ServiceAccount Token）

来看一个典型的风险点——应用访问 Token。

每当 Pod 绑定了一个 ServiceAccount，Kubernetes 就会把该账号的 Token 自动挂载进 Pod（除非显式关闭）。这意味着： 攻击者只要进入容器，就能获取这个 Token。

这些 Token 常用于服务间调用，有权限访问敏感资源。攻击者甚至可以用它操作 kube-apiserver，继续下一步攻击。

并不是所有 Token 都危险…但有不少确实很危险，例如，当一个 Token 拥有读取 Secret 的权限时：攻击者可以直接请求集群管理员的 Token。那k8s就是彻底沦陷了。

“灰色地带”：拥有创建 Pod 权限到底危险吗？

看起来不那么明显，但实际上风险极高：

原因有两个：

创建 Pod 时，你可以指定任意命令执行
更危险的是，你可以指定挂载任意 ServiceAccount

这意味着攻击者可以直接挂载高权限账号 → 完成权限提升 → 集群沦陷。

云托管 Kubernetes vs 自建 Kubernetes

控制面管理：AKS / EKS / GKE VS 自建集群

使用云厂商的托管 Kubernetes（如 AKS、EKS、GKE、ACK、CCE 等），其优点是控制面由云厂商维护，包括：

• API Server
• 调度器
• 控制器管理器

这样团队可以减少运维压力，专注业务。

而自建集群则需要自己负责：

• 升级
• 安全补丁
• 控制面可用性
• 扩缩容

更灵活，但需要大量专业能力。

风险评估：云与 Kubernetes 的复杂性

云托管一定更安全吗？ 未必。

虽然云托管减少了部分运维风险，但企业依然需要理解 Kubernetes 本身的安全逻辑，否则可能在权限映射、节点角色等方面出现新的攻击面。

案例：AWS EKS 特定攻击向量（权限映射漏洞）

由 An Trinh 与 Duc Nguyen 在 Calif 博客公开的一种攻击方式展示了一个典型风险： 攻击者只需要控制一个低权限 Pod，最终就能接管整个集群。

攻击分三阶段：

Phase 1：获取临时 Token

攻击者在 Pod 中调用 AWS API 请求一个 Kubernetes Token。

STS 会询问“你是哪台机器？” 回答来自 EC2 节点，而不是 Pod。

然后 AWS IAM 会把节点角色（NodeInstanceRole）映射到 Kubernetes 的 system:node 权限。

问题就在这： AWS 权限系统与 Kubernetes 权限系统本质不同，但此处发生了映射。

Phase 2：权限提升

攻击者利用 system:node 权限，就能获取同节点上其他 Pod 的 Token。

Phase 3：横向移动

进一步获取更多具备高权限的 Token，最终可能取得整个集群的管理控制权限。

总结

Kubernetes 强大但复杂，而复杂就意味着需要更深入的安全理解。

我们特别建议深入掌握：

高风险角色与权限
Pod 的安全配置
服务账号 Token 的风险点
节点与控制面的权限关系

只有理解攻击者的思路，企业才能真正保护好自身的 Kubernetes 集群与业务数据。