技术博客

Kubernetes DRA 安全加固:ResourceClaim、RBAC 和设备权限怎么管?

DRA 增强了 Kubernetes 设备管理能力,也带来新的授权边界。本文整理 DRA 安全加固中 ResourceClaim、状态更新和最小权限配置的运维重点。

Kubernetes安全DRARBACResourceClaim

Dynamic Resource Allocation 让 Kubernetes 能更灵活地分配 GPU、NPU、RDMA 网卡等设备资源。能力越强,权限边界就越重要。普通用户能不能创建 ResourceClaim?DRA 驱动能不能更新状态?调度器需要哪些字段?这些问题如果没有管好,设备资源可能被误用,甚至影响集群安全。

Kubernetes 官方 DRA 安全加固文档强调,DRA 组件会更新 ResourceClaim 状态,管理员应该使用显式、最小权限的 RBAC 控制这些更新。Kubernetes v1.36 还引入了更细粒度的 synthetic subresources 和 node-aware verbs。

DRA 为什么需要单独加固

传统 Pod 权限主要围绕命名空间、镜像、Secret、ServiceAccount、PodSecurity。DRA 引入了设备资源声明和状态更新,新增了几个风险点:

GPU 集群里,设备本身很贵,也可能承载敏感模型和数据。权限不能随便放大。

哪些对象要限制

建议区分角色:

集群管理员:

命名空间用户:

DRA 驱动:

调度相关组件:

排查权限问题

使用 kubectl auth can-i 验证权限:

kubectl auth can-i create resourceclaims -n ai-team-a --as system:serviceaccount:ai-team-a:runner
kubectl auth can-i update resourceclaims/status -n ai-team-a --as <driver-sa>
kubectl auth can-i create deviceclasses --as <normal-user>

普通用户如果能创建或修改集群级 DeviceClass,要立刻收紧权限。

查看相关对象:

kubectl get deviceclasses
kubectl get resourceclaims -A
kubectl describe resourceclaim <name> -n <namespace>
kubectl get clusterrole,clusterrolebinding | grep -i dra

最小权限建议

第一,DeviceClass 和 ResourceSlice 管理权限只给管理员和 DRA 驱动。

第二,ResourceClaim 创建权限按命名空间授予,不要全局放开。

第三,status 更新权限单独授权,不要用 * 覆盖。

第四,DRA 驱动使用独立 ServiceAccount,不和普通工作负载共用。

第五,启用审计日志,记录 ResourceClaim、DeviceClass、ResourceSlice 变更。

第六,结合 ResourceQuota 或 admission policy 控制命名空间可申请的设备数量。

GPU 多租户还要关注什么

DRA 只是一部分。GPU 多租户还要关注:

如果用 HAMi、MIG、vGPU 或其他共享机制,还要把它们的控制面权限一起纳入审计。

常见问题 FAQ

普通开发者可以创建 ResourceClaim 吗?

可以按命名空间授权,但不应允许他们修改 status,也不应允许他们管理 DeviceClass。

DRA 安全是不是只靠 RBAC?

不是。RBAC 是基础,还要结合审计、配额、准入策略、节点隔离和运行时安全。

为什么 status 更新要单独管?

状态字段会影响设备是否被认为已分配、已准备或失败。如果任何组件都能改,调度和设备生命周期会失真。

现在没有 DRA,还需要关注吗?

如果未来要做 GPU / AI 基础设施,建议提前理解。等生产已经跑起来再补权限,成本更高。

参考资料