Kubernetes RBAC 通过外部认证系统提供身份标识（User/Group/ServiceAccount），结合 Role/ClusterRole 定义权限，再用 RoleBinding/ClusterRoleBinding 绑定主体与权限；权限累加、无拒绝机制，需注意作用域、命名空间匹配及 API Group 正确性。
Kubernetes 通过 RBAC 实现用户权限管理，核心不是直接管理“用户”，而是将外部认证系统（如 X.509 证书、OIDC）提供的身份标识（即 User 字符串）与预定义的权限规则关联起来。整个过程不依赖集群内置用户系统，而是靠 Role/ClusterRole 定义“能做什么”，再通过 RoleBinding/ClusterRoleBinding 把权限分配给具体的 User、Group 或 ServiceAccount。
明确权限主体（Subject）是谁
RKAC 中的“用户”实际是认证阶段产生的身份标识，常见有三类：
- User：由外部系统认证后传入的用户名（例如证书中 CN 字段值），Kubernetes 不存储也不管理它，仅作为字符串使用
-
Group：一组 User 的逻辑集合，便于批量授权（如
system:authenticated是所有通过认证用户的默认组） - ServiceAccount：集群内应用最常用的身份，自动绑定到 Pod，适合服务间调用
注意：你不能用 kubectl create user 创建用户，必须先通过证书或 OIDC 等方式完成认证，再在 RBAC 对象中引用该用户名。
定义权限范围：Role vs ClusterRole
权限规则本身由 Role 或 ClusterRole 描述，区别在于作用域：
-
Role 只能在单个命名空间内定义资源操作，比如允许在
dev命名空间中对pods执行get和list -
ClusterRole 是集群级对象，可覆盖两类资源：
– 集群范围资源（如nodes、persistentvolumes）
– 所有命名空间内的资源（如任意 namespace 下的secrets、deployments）
即使只操作某一个命名空间的资源，若需复用同一套规则到多个命名空间，也建议用 ClusterRole + RoleBinding，更易维护。
完成权限绑定：RoleBinding / ClusterRoleBinding
绑定是连接“谁”和“能做什么”的关键步骤：
-
RoleBinding 在指定命名空间内，把 Role 绑定到 Subject 上；它不能引用 ClusterRole 来授予集群级权限（除非配合
cluster-admin这类特殊内置角色） -
ClusterRoleBinding 在集群范围内生效，常用于授予全局权限，比如让运维组拥有
cluster-admin权限，或让监控系统读取所有 namespace 的 metrics
示例场景：为用户名 alice 授予 default 命名空间的 pod 查看权，需同时创建 Role 和 RoleBinding，并确保两者 namespace 一致、roleRef 名称匹配。
验证与调试权限是否生效
权限配置后容易因拼写错误、命名空间错位或 API Group 不匹配而失效。常用验证方式：
- 用目标用户凭据执行
kubectl auth can-i --list查看当前可执行操作 - 模拟请求：
kubectl auth can-i list pods -n default --as=alice - 检查绑定关系：
kubectl get rolebinding,clusterrolebinding --all-namespaces并确认 subjects 字段正确 - 留意 verbs 是否覆盖所需动作（
get不等于exec，pods不包含pods/log）
权限是累加的，没有拒绝规则；多个绑定同时存在时，只要任一满足条件，请求即被允许。
