K8s RBAC

费曼核心：用大白话+生活化类比，拆掉专业黑话，讲清「是什么→为什么→核心组件→怎么用→关键区别」，咱们把 K8s 集群比作公司办公楼，一次性把 RBAC 刻进脑子里。

一、先搞懂：RBAC 到底是干嘛的？（解决啥问题）

你之前学过，先唤醒记忆： RBAC = Role-Based Access Control，基于角色的访问控制

K8s 集群里有各种资源：Pod、Node、Deployment、Secret、ConfigMap…… 如果所有人都能随便删 Pod、改节点、看密钥，集群直接炸了。

RBAC 就是 K8s 的**「门禁+权限管理制度」**： 规定「谁」能对「哪些资源」做「哪些操作」，多一分权限都不给。

---

二、终极类比：K8s 集群 = 公司办公楼

全程用这个类比，所有概念秒懂：

K8s RBAC 概念	公司办公楼类比	大白话解释
集群整体	整栋办公楼	所有资源的集合
命名空间(Namespace)	办公楼层/部门	比如3楼技术部、4楼财务部，相互隔离
Subject（主体）	员工/临时工/部门	要操作集群的人/账号
Role/ClusterRole（角色）	岗位说明书	写死了「这个岗位能干嘛」
RoleBinding/ClusterRoleBinding（绑定）	发工牌/授权	把「岗位」分配给「员工」
资源(Pod/Node等)	办公设备/文件柜	要操作的对象
操作(get/create/delete)	查看/开锁/搬走	对设备做的动作

核心逻辑一句话： 先写好岗位权限（Role），再把岗位分给员工（Binding），员工就只能干岗位允许的事。

---

三、拆解 RBAC 4大核心组件（必记，无废话）

1. Subject：谁要操作集群？（被授权的对象）

就是**「操作人」**，只有3类：

1. User：真实人类用户（运维、开发、测试）
2. ServiceAccount（SA）：程序/ Pod 用的账号（比如Prometheus、Ingress要访问K8s API，必须用SA）
3. Group：用户组（批量授权，比如给所有开发授权）

日常运维90%用 ServiceAccount，因为Pod里的组件要调用K8s API，必须用SA。

2. Role & ClusterRole：岗位说明书（定义权限）

只定义「能做什么」，不分配给谁，分两种：

① Role：命名空间级权限

• 作用范围：仅单个 Namespace 内有效
• 管的资源：Pod、Deployment、Service 等命名空间级资源
• 类比：楼层管理员，只管3楼技术部，管不到4楼财务部

② ClusterRole：集群级权限

• 作用范围：整个集群 所有命名空间
• 管的资源：Node、Namespace、PV 等集群级资源 + 所有命名空间资源
• 类比：物业总经理，整栋楼都能管

权限规则固定格式：apiGroups + resources + verbs 例：能对 pods 做 get、list、watch（查看、列表、监控）

3. RoleBinding & ClusterRoleBinding：发工牌（绑定授权）

把「角色（岗位）」分配给「Subject（员工）」，分两种：

① RoleBinding

• 绑定对象：Role 或 ClusterRole
• 作用范围：仅单个 Namespace
• 类比：把「3楼管理员」岗位，分给张三，张三只管3楼

② ClusterRoleBinding

• 绑定对象：只能是 ClusterRole
• 作用范围：整个集群
• 类比：把「总经理」岗位，分给运维主管，主管管整栋楼

---

四、最关键的2组区别（你之前模糊的点，一次性理清）

区别1：Role vs ClusterRole

• Role：小权限，锁死在一个命名空间，管不了集群资源（Node/PV）
• ClusterRole：大权限，覆盖全集群，能管集群资源+所有命名空间资源

区别2：RoleBinding vs ClusterRoleBinding

1. RoleBinding

   • 给单个命名空间授权
   • 可以绑定 Role 或 ClusterRole
   • 哪怕绑ClusterRole，权限也只在当前命名空间生效（缩容权限）

2. ClusterRoleBinding

   • 给整个集群授权
   • 只能绑定 ClusterRole
   • 权限全局生效

经典场景：用系统内置的 view ClusterRole + RoleBinding，给开发授权，开发只能看某个命名空间的资源，看不了其他空间。

---

五、极简实战例子（一看就懂，贴合运维场景）

需求：给 default 命名空间的 dev-sa 服务账号，只能查看Pod，不能删、不能改

步骤1：创建 ServiceAccount（员工）

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

步骤2：创建 Role（岗位说明书：只能看Pod）

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [""] # 核心API组，Pod属于这个组
  resources: ["pods"]
  verbs: ["get", "list", "watch"] # 仅查看权限

步骤3：创建 RoleBinding（发工牌：把岗位给SA）

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: default
subjects:
- kind: ServiceAccount
  name: dev-sa
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

结果：dev-sa 只能看default的Pod，删Pod、建Deployment都会报错权限不足。

---

六、费曼复盘：3句话总结 RBAC（永久记住）

1. RBAC 是 K8s 的权限管家，核心是「谁→能对啥→做啥」
2. 两大角色：Role（单命名空间）、ClusterRole（全集群）
3. 两大绑定：RoleBinding（单空间授权）、ClusterRoleBinding（集群授权） → 先定义角色权限，再绑定给账号，权限就生效了

---

七、补一个你运维常用的内置角色（加分）

K8s 自带内置ClusterRole，不用自己写：

• view：只读权限（看资源）
• edit：读写权限（改资源，不能授权）
• admin：命名空间管理员
• cluster-admin：集群超级管理员（慎用，权限拉满）

比如给开发只读权限，直接用 view + RoleBinding 就行，不用手写Role。

你现在随便想一个场景（比如给Prometheus授权、给开发授权），都能套这个逻辑，彻底吃透了。