Kubernetes RBAC 安全风险研究

绿盟科技/梅花K战队王伟 01 02 集群RBAC风险RBAC风险介绍 K8S授权认证基本概念介绍 目录 04 03 实战研究场景研究 安全防御策略主动防御 kubernetes授权认证流程 •开始请求：用户或应用服务对API Server发起任意操作行为。•认证检查：确认身份来源与合法性（证书、令牌、OIDC等认证方式）。•授权检查：依据策略判定是否允许目标动作（RBAC/ABAC/Node/Webhook）。•准入控制：对对象进行“修改与校验”，确保规格合规后才落库。•数据写入：最终资源写入etcd，并被调度/控制器消费与下发。 配置风险：默认服务账户 在Kubernetes中，每个命名空间都有一个名为default的Service Account。如果未明确禁用或替换，新创建的Pod默认会使用这个Service Account。如果这个default Service Account被绑定了高权限，那么任何在该命名空间中运行的Pod都可以继承这些高权限，即使它们不需要。 配置风险：权限过度授予 ClusterRole中使用verbs: ["*"]和resources: ["*"]：这种配置赋予了用户或服务账户cluster-admin级别的权限，可以对集群中的所有资源执行任何操作。即使是在Role中对特定命名空间赋予["*"]权限，也相当于该命名空间的管理员，可能导致横向渗透。 •开发环境直接使用cluster-admin•CI/CD绑定cluster-admin权限•监控系统获得不必要的集群管理权限•日志收集器拥有所有命名空间访问权 配置风险：身份冒用-impersonate权限 在容器中获取当前容器的SA配置信息确定是否具备可以利用的可能 配置风险：pods资源组配置错误 攻击者通过kubectl auth can-i --list查看当前容器的SA账户对应的rbac权限，发现可以对apigroups的pods组资源进行create的操作，这就可以通过该SA进行特权容器的创建从而逃逸获取集群权限 配置风险：Webhook配置错误 核 心 风 险 ： • R B A C权 限 本 身 无 法 阻 止 特 权 容 器 创 建•需 依 赖W e b h o o k服 务 进 行 准 入 控 制•f a i l u r e Po l i c y配 置 不 当导 致 安 全 防 线 失 效 配置风险：ServiceAccount过度授权 容器中的SA权限针对secrets的信息获取权限配置错误导致安全风险 配置风险：ServiceAccount过度授权利用 攻 击 者 根 据 收 集 到 的 信 息 ， 进 行 相 关 资 源 的 操 作 ，本 案 例 中s e c r e t s直 接 被 读 取 获 取 敏 感 信 息 攻 击 者 通 过 在 容 器 中 使 用k u b e c t l a u t hc a n - i - - l i s t查 看 当 前 容 器 的S A的 权 限 ， 收集 本 容 器 的S A账 户 权 限 进 行 下 一 步 攻 击 RBAC攻击流程 影响:攻击的最终目标,包括数据泄露、服务中断、集群接管等。 RBAC权限发现:攻击者会积极寻找可利用的RBAC权限,这是权限提升的关键一步。 权限提升:利用各种漏洞和配置缺陷,获取更高的权限,例如绑定高权限角色、模拟节点等。 RBAC权限利用:攻击者利用发现的权限,尝试创建或修改资源,以达到提升权限或横向移动的目的。 OIDC认证场景 错误配置示例：apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:name: cas-bindingroleRef:apiGroup: rbac.authorization.k8s.iokind:ClusterRolename: cluster-adminsubjects:- kind: Groupname: "cas-user" 风险点：•CAS用户组直接映射为K8s 高权限角色•缺乏细粒度的权限控制（由RBAC决定）•一旦CAS账号被攻破，K8s集群可能会被完全攻陷 微服务架构调用关系 •四层架构：接入层→应用层→业务层→数据层•每个服务使用独立的ServiceAccount•服务间通过K8s Service进行通信 用户的请求首先经过API Gateway，然后到达Web应用。当用户登录时，Web应用会调用认证服务验证身份；当用户下单时，会调用订单服务处理业务逻辑。 那么我们作为攻击者需要考虑的是，企业人员对于各个微服务的容器sa权限配置是否合理？ 微服务攻击链 web应用容器：仅能查看Pod和Service信息。 认证服务：可以读取所有Secrets，方便用于用户身份认证，未做到权限最小化原则，服务sa的token可能具备查看所有secrets的权限。 订单服务：方便调试订单，开发人员可能过度授予权限。 •任意漏洞利用比如上传等•获取web容器的初始Shell•信息收集ServiceAccount Token值•发现认证服务有secrets权限•窃取JWT密钥•伪造管理员Token•最终获取集群权限或者影响业务订单 Nexus集成架构与风险点 Nexus Repository是一个仓库管理器，主要的作用是存储和管理：Maven、Docker、npm、Python等各种制品代理缓存：缓存外部仓库（如Docker Hub、Maven Central）私有仓库：托管企业内部的镜像和依赖包访问控制：管理镜像的上传/下载权限 •镜像投毒风险•凭据泄露风险•供应链攻击•Nexus服务漏洞 Nexus突破路径 攻击初始：Nexus未授权访问安全问题：代码+密码凭据泄露目标明确：Kubernetes集群控制权 三条攻击路径：1.K8s配置文件→直连集群2.令牌复用→Harbor→K8s3.密码登录→Harbor→K8s 防护关键：Nexus访问控制+凭据加密 Nexus未授权突破集群防御 通过访问nexus镜像仓库平台，发现重要镜像，代码等敏感信息，通过下载镜像文件，代码，maven打包，镜像打包等日志进行分析，发现配置容器运行时命令中带有明文密码，突破到主机终端权限。 RBAC攻击流程总结 日常防护 RBAC防御的第一道防线是日常积极正确的安全运维与开发，从源头降低攻击面。在业务层面，我们必须严格遵循最小权限原则，并定期审查RBAC策略，确保权限配置的合理性。在架构与构建层面，通过将安全策略左移，在代码提交和部署阶段就进行强制检查。利用准入控制器在API Server层面拦截高风险操作，配合及时更新Kubernetes版本，共同构建起坚实的安全基石 持续改进修复方案 通过启用API Server审计日志和持续监控集群安全事件，我们可以快速发现RBAC滥用行为，应急人员进行深入的溯源分析，确定攻击的入口机器以及内网横向中涉及到的容器与账户，持续改进防御策略和一些容器的错误配置，从而不断提升集群的整体安全韧性。 谢谢观看 2025-11-15