RBAC — 谁能做什么

为什么需要 RBAC？

一个集群里有运维、开发、测试、CI/CD 流水线，它们需要不同的权限：

  • 开发人员：只能看 dev 命名空间的 Pod 日志
  • CI/CD：只能在 prod 命名空间部署 Deployment
  • 运维：可以管理所有资源但不能删 PV
  • 监控系统：只能读取 metrics

RBAC（Role-Based Access Control）就是 K8s 的权限体系。

四个核心概念

谁(Subject) + 能做什么(Role) = 绑定(Binding)

Subject（三种）:
  ├── User        (人，K8s 不管理用户，由外部认证)
  ├── Group       (用户组)
  └── ServiceAccount (程序身份，K8s 管理)

Role（两种）:
  ├── Role            (命名空间级)
  └── ClusterRole     (集群级)

Binding（两种）:
  ├── RoleBinding         (在某个命名空间内绑定)
  └── ClusterRoleBinding  (集群级绑定)

权限矩阵

RoleClusterRole
RoleBinding只在该 NS 生效在该 NS 内使用集群角色
ClusterRoleBinding❌ 不合法集群范围生效

典型组合：

  1. Role + RoleBinding → "张三可以在 dev 空间读 Pod"
  2. ClusterRole + RoleBinding → "张三可以在 dev 空间用 view 角色"（复用内置 ClusterRole）
  3. ClusterRole + ClusterRoleBinding → "监控系统可以读所有空间的 metrics"

我们的实操

1. 创建 ServiceAccount

kubectl -n dev create serviceaccount developer

ServiceAccount 是给程序用的身份。每个 Pod 默认挂载所在 namespace 的 default ServiceAccount。创建自定义 SA 可以给特定程序精确的权限。

2. 创建 Role

kubectl -n dev create role pod-reader \
  --verb=get,list,watch \
  --resource=pods,pods/log

等价 YAML：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: dev
rules:
- apiGroups: [""]              # "" 表示核心 API 组（pods, services 等）
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

verb 对应的操作：

Verb含义kubectl 命令
get读取单个kubectl get pod nginx-xxx
list列出所有kubectl get pods
watch监听变化kubectl get pods -w
create创建kubectl create / kubectl apply
update更新kubectl edit / kubectl apply
patch部分更新kubectl patch
delete删除kubectl delete

子资源（subresource）：

  • pods/log — Pod 日志（kubectl logs）
  • pods/exec — 进入容器（kubectl exec）
  • pods/portforward — 端口转发
  • deployments/scale — 扩缩容

3. 创建 RoleBinding

kubectl -n dev create rolebinding developer-read \
  --role=pod-reader \
  --serviceaccount=dev:developer

4. 验证权限

# 模拟 developer SA 的身份检查权限
$ kubectl -n dev auth can-i list pods --as=system:serviceaccount:dev:developer
yes     ✓ 有权限

$ kubectl -n dev auth can-i delete pods --as=system:serviceaccount:dev:developer
no      ✗ Role 只给了 get/list/watch

$ kubectl -n dev auth can-i list deployments --as=system:serviceaccount:dev:developer
no      ✗ Role 只授权了 pods 资源

$ kubectl -n prod auth can-i list pods --as=system:serviceaccount:dev:developer
no      ✗ Role 只在 dev 命名空间

K8s 内置的 ClusterRole

K8s 自带几个常用 ClusterRole，不需要自己创建：

ClusterRole权限范围
view只读大部分资源（不含 Secret）
edit读写大部分资源（不含 RBAC）
admin命名空间内的完全管理权限
cluster-admin集群最高权限（相当于 root）
# 给 developer 在 dev 空间的 edit 权限（用内置 ClusterRole）
kubectl -n dev create rolebinding developer-edit \
  --clusterrole=edit \
  --serviceaccount=dev:developer

面试深度题

Q: User 和 ServiceAccount 的区别？

UserServiceAccount
管理者K8s 外部（LDAP、OIDC、证书）K8s 内部（kubectl create sa）
存储不存在 K8s 中存为 K8s 资源对象
用途人类操作 kubectl程序/Pod 调用 API
作用域集群全局命名空间级
Token手动管理自动挂载到 Pod

Q: 如何设计 CI/CD 的 RBAC？

# 1. 创建专用 SA
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ci-deployer
  namespace: prod

# 2. 精确授权：只能操作 Deployment 和 Service
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployer
  namespace: prod
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["services"]
  verbs: ["get", "list", "create", "update"]

# 3. 绑定
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ci-deployer-binding
  namespace: prod
subjects:
- kind: ServiceAccount
  name: ci-deployer
  namespace: prod
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io

原则：最小权限。 CI/CD 不需要 delete 权限（防止误删），不需要访问 Secret（密码通过 External Secrets Operator 管理），不需要操作其他 namespace。

Q: 有人在 prod 空间里删了重要的 Deployment，怎么查？

答案：审计日志（Audit Log）。K8s API Server 支持记录所有 API 请求，包括谁、什么时间、做了什么操作。Phase 3 会配置审计日志。

Phase 1 总结

主题核心收获
Namespace资源隔离、权限隔离、配额隔离
Deployment滚动更新、回滚、ReplicaSet 版本管理
ServiceClusterIP/NodePort、DNS 发现、Endpoints
ConfigMap/Secret配置外置、base64≠加密、volume 更新 vs env 不更新
StatefulSet有序命名、稳定 DNS、独立 PVC
DaemonSet每节点一份、自动跟随节点
Job/CronJob批处理、并行度、concurrencyPolicy
RBACRole/ClusterRole、最小权限、ServiceAccount
metrics-serverkubectl top 节点/Pod 资源监控基础

→ Phase 2: 中级技能