Kubernetes AI环境中RBAC不足以实现真正的租户隔离
2026/05/05 02:26阅读量 2
RBAC（基于角色的访问控制）仅控制Kubernetes API层操作，无法应对容器逃逸、网络横向移动、共享API服务器等威胁。Namespace并非安全边界，企业AI多租户场景需要更底层的隔离机制，包括节点隔离、网络策略和强化的控制平面安全。
事件概述
在企业AI环境中，多个团队共享Kubernetes集群时，RBAC（基于角色的访问控制）是常见的权限管理手段，但它无法实现真正的租户隔离。RBAC仅控制API层的操作权限，对于容器逃逸、网络横向移动、控制平面共享等威胁无能为力。Kubernetes的Namespace也不是一个安全边界，集群范围内的资源（如Nodes、PersistentVolumes、StorageClasses等）不受Namespace限制。
核心信息
- RBAC的不足：RBAC只影响Kubernetes API层的授权，而底层存在多个盲点：
- 共享API服务器：所有租户共用同一个API服务器和etcd后端。如果API服务器存在漏洞或Pod逃逸后直接访问API服务器，RBAC绑定可能被绕过。
- 节点级别暴露：Pod可能被调度到同一节点上。一旦发生容器逃逸（如runc CVE-2019-5736、Linux内核CVE-2022-0185），攻击者可获得宿主机文件系统、进程表和网络接口访问权限，进而查看所有同节点工作负载。
- 网络可达性：默认Kubernetes网络允许跨Namespace的任意Pod间通信。若未配置NetworkPolicy，一个团队的Pod可以直接访问另一团队的模型服务端点、向量数据库等，形成横向移动路径。
- Namespace非安全边界：Kubernetes官方文档明确指出Namespace仅用于资源逻辑分组，不是安全隔离手段。集群范围资源（如StorageClass、Node、PersistentVolume等）不受Namespace制约。
值得关注
这篇文章是“企业AI环境Kubernetes安全”系列的第一篇，后续将讨论Secret与凭据管理、GPU资源治理、生产模型服务安全。对于运行敏感AI工作负载（如金融、医疗）的企业，仅依赖RBAC存在严重风险，需引入节点亲和性规则、污点/容忍、以及强制性的NetworkPolicy来实现真正的多租户隔离。