川海智库

报告概述

这份报告系统研究了Kubernetes RBAC（基于角色的访问控制）机制中存在的安全风险。报告首先介绍了K8s的授权认证流程和四种主要认证方式，随后围绕RBAC的核心对象展开说明，重点剖析了默认服务账户、权限过度授予、身份冒用、pods资源组配置错误、Webhook配置错误以及ServiceAccount过度授权等典型配置风险。在此基础上，报告通过OIDC认证场景、微服务架构攻击链和Nexus仓库突破路径等实战研究，完整呈现了攻击者从初始访问到最终控制集群的利用过程，并提出了日常防护与持续改进的防御策略。报告适合云安全工程师、容器平台运维人员及安全测试人员参考，有助于识别和修复集群权限配置中的薄弱环节。

报告的核心结论

默认服务账户高权限绑定会导致权限继承风险

在Kubernetes中，每个命名空间都有default Service Account，新创建Pod默认使用它。如果这个账户被绑定了高权限角色，命名空间内所有Pod都会继承这些权限，即使业务并不需要。攻击者攻陷任意Pod后即可利用该身份执行高权限操作，因此应避免给默认服务账户授予业务无关权限。

通配符授权配置等同于集群管理员权限

当ClusterRole或Role中使用verbs:["*"]和resources:["*"]时，实际授予了目标作用域内的全部资源操作权限，相当于cluster-admin。报告指出开发环境直用cluster-admin、CI/CD绑定cluster-admin、监控系统和日志收集器获得过度权限，都会扩大攻击面，攻击者一旦获得此类身份即可完全控制集群或进行横向渗透。

RBAC本身无法阻止特权容器创建，需结合准入控制

RBAC权限管理的是“能否执行操作”，而特权容器的创建还受准入控制约束。如果仅依赖RBAC而不配置Webhook，或Webhook的failurePolicy配置不当，在准入服务不可用时就会放行高风险请求。因此必须用准入控制器拦截特权容器等危险对象，同时正确设置失败策略，确保安全防线有效。

攻击者常通过权限发现与利用实现集群接管

报告总结的攻击流程为初始访问、RBAC权限发现、权限提升、横向移动、权限利用与影响。攻击者攻陷一个Pod后，会先查看该容器的ServiceAccount权限，寻找可利用的高权限配置，再通过创建特权容器、读取Secrets、伪造身份等方式提升权限，最终导致数据泄露或集群控制权丧失。

报告回答的关键问题

Kubernetes RBAC 常见配置风险有哪些？

报告指出常见风险包括默认服务账户未禁用或替换、权限过度授予（如通配符权限）、身份冒用权限配置错误、pods资源组配置错误、Webhook准入控制配置错误以及ServiceAccount过度授权。这些配置会让攻击者获得本不应具备的操作权限，例如创建特权容器、读取Secrets、伪造高权限身份，进而实现容器逃逸、横向移动或集群接管。正确做法是遵循最小权限原则并定期审查RBAC策略。

为什么默认 Service Account 容易引发集群安全风险？

Kubernetes 为每个命名空间自动创建 default Service Account，新 Pod 默认挂载该身份。如果运维人员给这个账户绑定了高权限角色，命名空间内所有 Pod 都会继承这些权限，即使它们只运行普通业务。攻击者一旦利用应用漏洞进入任意 Pod，就能直接使用继承的权限进行敏感操作。因此应避免给 default 账户授予高权限，或显式指定专用的 ServiceAccount。

攻击者如何利用 ServiceAccount 过度授权读取敏感信息？

报告演示了当容器内的 ServiceAccount 对 secrets 资源拥有 get/list 权限时，攻击者通过 kubectl auth can-i --list 查看当前账户权限，发现可以访问 secrets，随后使用相应命令直接读取 Secret，获取集群中的凭据和敏感配置。这通常源于未遵循最小权限原则，为服务账户配置了超出业务所需的资源权限。

微服务架构下 RBAC 配置不当会造成什么影响？

在微服务架构中，每个服务使用独立的 ServiceAccount。报告以 Web 应用、认证服务和订单服务为例，若认证服务的 SA 拥有读取所有 Secrets 的权限，订单服务为了调试被过度授权，攻击者攻破 Web 容器后，可通过 SA Token 探测其他服务权限，窃取 JWT 密钥、伪造管理员 Token，最终获取集群权限或影响业务。因此必须按业务需要为每个服务分配最小权限。

如何有效防御 Kubernetes RBAC 权限攻击？

报告提出了日常防护和持续改进两层策略：遵循最小权限原则并定期审查 RBAC 策略；将安全策略左移，在代码提交与部署阶段强制检查；利用准入控制器拦截高风险操作；及时更新 Kubernetes 版本；启用 API Server 审计日志和持续监控安全事件，以便快速发现滥用行为并进行溯源，不断修复错误配置。

完整报告包含什么

  • Kubernetes 授权认证全流程解析：从用户或应用服务对 API Server 发起操作请求开始，依次经过认证检查、授权检查、准入控制和数据写入等环节，详细说明每个阶段的作用、常见实现方式（如证书、令牌、OIDC、RBAC/ABAC/Node/Webhook）以及可能被攻击者利用的薄弱点，帮助读者完整理解一次请求如何被处理以及安全控制点在哪里。
  • 四种主流认证方式的风险对比：分别介绍客户端证书 X.509、Webhook、OIDC 和 ServiceAccount 的认证原理与配置方式，并逐一分析对应的安全风险，包括证书泄露与 CA 管理问题、Webhook 服务自身漏洞与配置复杂性、OIDC 的 Token 泄露与配置错误、ServiceAccount 的 Token 泄露和不安全权限配置等，为选择认证方案提供风险参考。
  • RBAC 核心对象与权限模型详解：围绕 Role、ClusterRole、RoleBinding、ClusterRoleBinding 四个核心概念，解释它们各自的定义、作用范围与适用场景，说明为什么 Role 只能限定在特定命名空间，ClusterRole 可以管理集群级资源或跨命名空间聚合权限，并梳理主体、资源、动词（API 组、资源、动作）之间的绑定关系，为后续安全分析奠定基础。
  • 典型配置风险场景还原：报告重点剖析了六类高发配置问题——默认服务账户未禁用或替换、权限过度授予（如 verbs:["*"] 和 resources:["*"]）、身份冒用（impersonate）权限配置不当、pods 资源组可 create 权限、Webhook 准入控制 failurePolicy 配置错误、ServiceAccount 对 secrets 的过度授权。每个场景都结合 kubectl 命令和实际利用方式，展示攻击者如何从低权限容器一步步获得集群控制权。
  • 实战场景研究：OIDC 错误配置、微服务架构攻击链、Nexus 集成风险与突破路径。OIDC 场景展示 CAS 用户组直接映射为 cluster-admin 的风险；微服务场景模拟 Web 应用、认证服务、订单服务之间的调用关系，演示攻击者通过 Web 容器获取 SA Token、读取 Secrets、窃取 JWT 密钥并伪造管理员 Token 的全过程；Nexus 场景则展示未授权访问仓库、获取明文密码和镜像代码，最终突破到主机终端权限的攻击路径。
  • RBAC 攻击流程总结：报告将攻击者的行为归纳为五个阶段——初始访问、RBAC 权限发现、权限提升、横向移动、权限利用与影响。每个阶段都有明确的目标和动作，例如在权限发现阶段通过 kubectl auth can-i --list 列出可用权限，在权限提升阶段绑定高权限角色或模拟节点等。理解这一流程有助于安全团队在攻击链的各个节点设置检测和阻断措施。
  • 主动防御策略体系：防御部分提出两层策略。日常防护方面，遵循最小权限原则、定期审查 RBAC 策略、将安全策略左移在代码提交和部署阶段强制检查、利用准入控制器拦截高风险操作、及时更新 Kubernetes 版本。持续改进方面，启用 API Server 审计日志、持续监控集群安全事件、进行应急溯源分析，确定攻击入口机器以及内网横向涉及的容器与账户，并持续修复错误配置。
  • 可操作的安全检查方法：报告提供了多个具体命令示例，如使用 kubectl auth can-i --list 查看当前 ServiceAccount 的权限列表，使用 kubectl exec --as=system:serviceaccount:rbac-vuln:admin-sa 模拟其他身份执行操作，帮助安全人员快速验证权限配置是否合理。这些命令同样适用于渗透测试中的权限探测，能够有效发现过度授权和身份冒用等风险。

本页内容由川海智库整理，用于帮助读者快速了解报告主题、核心观点和主要内容。由于报告量大、人工能力有限，部分观点、数据、统计口径或表述可能存在偏差，具体内容请以完整报告原文为准。

相关报告