深入掌握 Kubernetes RBAC 权限模型：从原理到实战

RBAC（Role-Based Access Control）是 Kubernetes 中最核心、最常用的权限控制模型。无论你是平台管理员、SRE，还是 K8s 应用开发者，只要你需要安全地管理集群访问，RBAC 都是绕不过去的。

本篇文章将用“易懂 + 专业 + 示例驱动”的方式，从底层概念到实战案例帮你完全吃透 RBAC。

1. RBAC 是什么？为什么必须掌握？

RBAC = 根据角色分配权限。在 Kubernetes 中，它控制：

• 用户能做什么（verbs）

• 能操作哪些资源（pods、deployments…）

• 作用范围（namespace / cluster）

Kubernetes 不会直接给用户权限，而是让用户绑定角色，角色里定义了权限。

RBAC 可以解决如下问题：

• 开发人员误删 Pod

• CI/CD 仅读 Pod 却无法创建 Deployment

• 用户报 Forbidden 403

• 多 namespace 场景的权限隔离

2. Kubernetes RBAC 核心概念

RBAC 一共有 4 种对象：

对象	作用范围	作用
Role	namespace	定义某个命名空间内的权限
ClusterRole	全局	定义集群级别权限
RoleBinding	namespace	绑定 Role 或 ClusterRole 给用户
ClusterRoleBinding	全局	将 ClusterRole 绑定给用户（全局生效）

关键词：

• Role = 权限列表

• Binding = 用户与角色的关系

• ClusterRole = 跨命名空间或全局资源

3. Role / ClusterRole：权限如何定义？

权限由以下三部分组成：

• apiGroups

• resources

• verbs

Role 示例（命名空间级，只读 Pod）

 apiVersion: rbac.authorization.k8s.io/v1
 kind: Role
 metadata:
   name: pod-reader
   namespace: dev
 rules:
   - apiGroups: [""]
     resources: ["pods"]
     verbs: ["get", "list", "watch"]

ClusterRole 示例（全局管理 Node）

 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
   name: node-reader
 rules:
   - apiGroups: [""]
     resources: ["nodes"]
     verbs: ["get", "list"]

4. RoleBinding / ClusterRoleBinding：绑定角色给用户

RoleBinding 示例（绑定 Role 给用户）

 apiVersion: rbac.authorization.k8s.io/v1
 kind: RoleBinding
 metadata:
   name: bind-pod-reader
   namespace: dev
 subjects:
   - kind: User
     name: alice
     apiGroup: rbac.authorization.k8s.io
 roleRef:
   kind: Role
   name: pod-reader
   apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding 示例（全局权限绑定）

 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
   name: bind-read-all
 subjects:
   - kind: User
     name: bob
     apiGroup: rbac.authorization.k8s.io
 roleRef:
   kind: ClusterRole
   name: cluster-admin
   apiGroup: rbac.authorization.k8s.io

5. verbs / resources / apiGroups 速查表

Verbs 常见动作

动作	含义
get	读取
list	列表
watch	监听
create	创建
update	更新
patch	局部更新
delete	删除
exec	执行容器命令
use	使用特定权限（如 PSP）

常见资源

资源	APIGroup
pods	""
deployments	apps
services	""
nodes	""
configmaps	""
secrets	""
ingress	networking.k8s.io
crd	apiextensions.k8s.io

6. 常用权限场景示例

#### 示例 1：只允许查看 Pod（命名空间级）

 rules:
   - apiGroups: [""]
     resources: ["pods"]
     verbs: ["get", "list", "watch"]

示例 2：开发人员管理 Deployment，但不能删除

 verbs: ["get", "list", "watch", "create", "update", "patch"]

示例 3：允许查看 Node（ClusterRole）

 resources: ["nodes"]
 verbs: ["get", "list"]

示例 4：允许执行 Pod exec

 resources: ["pods/exec"]
 verbs: ["create"]

示例 5：日志查看

 resources: ["pods/log"]
 verbs: ["get", "list"]

示例 6：CRD 管理

 apiGroups: ["apiextensions.k8s.io"]
 resources: ["customresourcedefinitions"]
 verbs: ["*"]

7. Pod 中应用授权（ServiceAccount）

创建 ServiceAccount

 apiVersion: v1
 kind: ServiceAccount
 metadata:
   name: app-sa
   namespace: dev

绑定 Role

 kind: RoleBinding
 subjects:
   - kind: ServiceAccount
     name: app-sa
     namespace: dev
 roleRef:
   kind: Role
   name: pod-read

Deployment 指定 ServiceAccount

 spec:
   serviceAccountName: app-sa

8. 如何排查权限问题

 kubectl auth can-i create pods --as alice -n dev

• 输出 yes → 有权限

• 输出 no → 没权限

9. 企业级 RBAC 最佳实践

• 遵循最小权限原则

• 开发人员按 namespace 授权，不给全局权限

• 系统组件统一使用 ServiceAccount

• 高危权限拆分 Role

• 建立公司级标准 Role 库

• 避免直接给人类用户 cluster-admin

10. 总结

RBAC 核心就是：

 User / ServiceAccount
         ↓
 Binding (RoleBinding / ClusterRoleBinding)
         ↓
 Role / ClusterRole
         ↓
 Resources + Verbs

理解这条链，你就可以搭建干净、安全、可维护的权限体系。