场景判断
RBAC 是三元组：Subject（人/ServiceAccount）→ Role 或 ClusterRole（动词与资源）→ Binding。排障时顺序固定：先 can-i 看当前身份与模拟身份，再查 bind，最后改清单。CI 机器人不该默认 cluster-admin；应用 Pod 的 default SA 也只该拿到它真的需要的 get/list/watch。
真实事故骨架：流水线 kubeconfig 绑了 cluster-admin，一次笔误 delete 了错误命名空间；另一边业务 Pod 用 default SA 调 API 被拒，开发却把 admin kubeconfig 打进镜像「先跑通」。权限过大与不足可以同时存在——can-i 是把预期写清楚的最低成本工具。
复现步骤
本机勾选备忘（localStorage），不代表你已在集群里跑过，也不连接任何 API。只是帮你对照步骤，别当成「学会了」的勋章。
— / 5本机勾选
- 01
- 02
- 03
- 04
- 05
关键配置
# examples/rbac/role-pod-reader.yaml（节选）
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: default
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
---
kind: RoleBinding
metadata:
name: read-pods
subjects:
- kind: ServiceAccount
name: default
namespace: default
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
# 当前身份
kubectl auth can-i get pods
kubectl auth can-i create deployments
# 模拟 default SA（apply 前后对比）
kubectl auth can-i get pods --as=system:serviceaccount:default:default
kubectl auth can-i delete pods --as=system:serviceaccount:default:default
kubectl apply -f examples/rbac/role-pod-reader.yaml
kubectl auth can-i get pods --as=system:serviceaccount:default:default
kubectl auth can-i delete pods --as=system:serviceaccount:default:default
kubectl delete -f examples/rbac/role-pod-reader.yaml
can-i 不是形式主义——它把「我觉得有权限」变成可复现的 yes/no 证据。
验收：你能口述 Forbidden 时的第一条命令，并演示「允许 get pods / 拒绝 delete pods」各一条 can-i。高阶交付清单会继续问你：流水线身份是谁、能否 undo、能否误删别的命名空间。
现场记录
先写自己的证据，再看参考答案。输入只留在当前页面，本站不会读取或验证你的集群。
最小权限：can-i 与 RoleBinding
这是你的手动确认，不代表本站已检测命令执行结果。
关联命令
跳转图鉴并展开对应条目（可复制示例）。
对应路径课节