一、RBAC是什么
RBAC（Role-Based Access Control，基于角色的访问控制）。它是 API Server 授权阶段的核心机制，负责决定“一个已认证的用户能否对某个资源执行某个操作”。
二、RBAC 四大核心资源
K8s RBAC 由 4 种 API 资源构成，全部属于 rbac.authorization.k8s.io/v1 组：
| 资源类型 | 作用范围 | 核心作用 |
|---|---|---|
| Role | 命名空间级别 | 定义单个命名空间内的权限集合 |
| ClusterRole | 集群级别 | 定义整个集群内的权限集合（可跨命名空间） |
| RoleBinding | 命名空间级别 | 将用户 / 用户组绑定到 Role，授予命名空间内权限 |
| ClusterRoleBinding | 集群级别 | 将用户 / 用户组绑定到 ClusterRole，授予集群级权限 |
关键概念补充
-
Subject（主体）：被授权的对象，包含 3 类：
User：普通用户（如运维人员、开发人员），K8s 不存储用户，需通过认证插件识别Group：用户组（如system:administrators）ServiceAccount：服务账户（Pod 内应用访问 APIServer 的身份）
-
Verb（操作动作）：对资源的操作权限，如
get/list/watch/create/update/delete -
Resource（资源）：被操作的 K8s 资源，如
pods/deployments/configmaps
三、角色（Role/ClusterRole）：定义权限集合
角色是权限的容器，只定义 “能做什么”，不关联具体用户。
1. 命名空间级角色：Role
- 作用域：仅对当前命名空间有效，无法跨命名空间
- 适用场景：给用户授予某命名空间内的资源权限（如开发人员操作
default命名空间的 Pod） - 配置示例（
default命名空间的 Pod 只读角色）
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:name: pod-readernamespace: default # 必须指定命名空间
rules:
- apiGroups: [""] # 核心组（core group）为空字符串resources: ["pods", "pods/log"] # 允许操作的资源verbs: ["get", "list", "watch"] # 允许的操作动作
2. 集群级角色：ClusterRole
-
作用域：整个集群，支持 3 类权限定义：
- 集群级资源：如
nodes/namespaces（只能用 ClusterRole 定义） - 跨命名空间的命名空间级资源：如允许用户查看所有命名空间的 Pod
- 自定义资源（CRD）：如 Operator 的 CR 权限
- 集群级资源：如
-
适用场景：集群管理员权限、跨命名空间权限、集群级资源权限
-
配置示例（集群级 Pod 只读角色）
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: cluster-pod-reader # 无 namespace 字段
rules:
- apiGroups: [""]resources: ["pods", "pods/log"]verbs: ["get", "list", "watch"]
- apiGroups: [""]resources: ["nodes"] # 集群级资源，只能用 ClusterRoleverbs: ["get", "list"]
四、绑定关系（RoleBinding/ClusterRoleBinding）：关联用户与角色
绑定是将用户与角色关联的桥梁，核心是 “给哪个用户分配哪个角色的权限”。
1. 命名空间级绑定：RoleBinding
RoleBinding 有 2 种绑定方式：
方式 1：绑定同命名空间的 Role（最常用）
给
user-dev用户授予default命名空间pod-reader角色的权限
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: pod-reader-bindingnamespace: default # 与 Role 同命名空间
subjects: # 被授权的用户
- kind: Username: user-dev # 用户名apiGroup: rbac.authorization.k8s.io
roleRef: # 绑定的角色kind: Role # 必须是 Rolename: pod-reader # 角色名apiGroup: rbac.authorization.k8s.io
方式 2：绑定 ClusterRole（实现 “命名空间内的集群角色权限”）
将 ClusterRole
cluster-pod-reader的权限限定在default命名空间内，用户只能操作该命名空间的 Pod
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: cluster-pod-reader-bindingnamespace: default
subjects:
- kind: Username: user-devapiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRole # 绑定 ClusterRolename: cluster-pod-readerapiGroup: rbac.authorization.k8s.io
核心价值：复用 ClusterRole 定义，避免重复创建 Role。
2. 集群级绑定：ClusterRoleBinding
- 作用：给用户授予集群级权限，权限覆盖整个集群
- 适用场景：集群管理员、跨所有命名空间的权限
- 配置示例（给
user-admin授予集群管理员权限）
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: cluster-admin-binding
subjects:
- kind: Username: user-adminapiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRolename: cluster-admin # K8s 内置的集群管理员角色apiGroup: rbac.authorization.k8s.io
绑定关系核心规则
-
roleRef是不可变的：绑定创建后，无法修改绑定的角色（只能删除重建） -
Subject 支持多类型：可同时绑定 User、Group、ServiceAccount
subjects: - kind: Username: user-devapiGroup: rbac.authorization.k8s.io - kind: Groupname: dev-groupapiGroup: rbac.authorization.k8s.io - kind: ServiceAccountname: app-sanamespace: default -
ClusterRoleBinding 只能绑定 ClusterRole：无法绑定 Role
五、内置 ClusterRole 与绑定（生产常用）
K8s 内置了一批常用角色，无需手动创建：
| 内置 ClusterRole | 权限描述 | 适用场景 |
|---|---|---|
cluster-admin |
集群所有资源的所有操作权限 | 集群管理员 |
admin |
命名空间内所有资源权限（除集群级资源） | 命名空间管理员 |
edit |
命名空间内资源的增删改查 | 开发人员 |
view |
命名空间内资源的只读权限 | 测试人员 |
六、常用命令
# 1. 查看角色
kubectl get roles -n default
kubectl get clusterroles# 2. 查看角色详情（权限规则）
kubectl describe role pod-reader -n default
kubectl describe clusterrole view# 3. 查看绑定关系
kubectl get rolebindings -n default
kubectl get clusterrolebindings