403 到底缺什么
Kubernetes 的 403 只说明某个主体不该做这个动作，却不会告诉你缺哪一个动词或哪一类资源。排查顺序因此固定：先确认「谁」在请求，再用鉴权自检确认缺什么，最后顺着绑定关系核对规则。身份判断错了，后面每一步都是在看别人的权限。
基本信息
| 适用平台 | Kubernetes 1.20+，RBAC 为默认鉴权模式 |
|---|---|
| 核心命令 | kubectl auth whoami、kubectl auth can-i、kubectl describe role |
| 常见主体 | 证书用户、ServiceAccount、系统组 |
| 必要权限 | 能读 Role、RoleBinding、ClusterRoleBinding 的账号 |
| 影响范围 | 命名空间级用 Role，集群级用 ClusterRole |
常见成因
- 主体搞错：本机 kubeconfig 用管理员证书，Pod 内却是 ServiceAccount，改的是另一个身份
- 命名空间错位：绑定建在 default，负载实际跑在 prod
- ServiceAccount 名称不一致：创建时叫 app-sa，引用时写成 app
- 授权粒度不足：给了 Pod 读写却没给事件与日志子资源，describe 与 logs 依旧 403
- 用了聚合角色：权限由多个 ClusterRole 合并而成，单看一个角色看不出全貌
排查命令
排查命令
kubectl auth whoami # 确认当前身份（旧版本用 config view --minify）
kubectl auth can-i get pods -n prod # 当前身份在 prod 能否读 Pod
kubectl auth can-i list pods --as=system:serviceaccount:prod:app-sa -n prod # 模拟 SA 验证
kubectl auth can-i --list -n prod --as=system:serviceaccount:prod:app-sa # 列出该主体全部允许动作
kubectl get rolebindings,clusterrolebindings -A -o wide | grep app-sa # 找到绑定位置
kubectl describe role read-pods -n prod # 核对 apiGroups 与资源名定位步骤
| 步骤 | 要看的信息 | 判断依据 |
|---|---|---|
| 确认身份 | 当前用户或 ServiceAccount 全名 | 与报错方声明的身份一致才算对上 |
| 验证动作 | 某动词加某资源的允许结果 | 能精确指出缺的是 get 还是 list |
| 定位绑定 | 角色绑定所在的命名空间 | 绑定命名空间与被访问命名空间相同才有效 |
| 核对规则 | apiGroups、resources、verbs | 核心组与 apps、batch 等 API 组要分别写 |
授权自检命令支持 --as 与 --as-group，用来模拟任意用户或服务账号；这是在不改动任何绑定的前提下验证权限的最快方式。
排查阶段不要用「先绑一个管理员角色试一下」的办法定位问题。验证通过后极易忘记回收，等于长期放开全集群权限。