can-i 是干什么的
kubectl auth can-i 回答一个明确问题：某个身份能不能对某个资源做某个动作。它把 RBAC 的判定结果以 yes 或 no 直接抛出来，配合 --as 还能模拟其他用户或 ServiceAccount，因此是排查 403 报错、验证授权是否按预期生效的首选命令。它默认只给结论，不解释是哪条 Role 或 RoleBinding 生效。
基本信息
| 语法 | kubectl auth can-i <动词> <资源> [--as=<身份>] [-n 命名空间] |
|---|---|
| 通配写法 | 用 * 表示全部动词或全部资源 |
| 范围限定 | --all-namespaces 检查集群范围 |
| 列清单 | --list 输出该身份被授予的全部规则 |
| 返回形式 | yes / no，也可用 -q 只看退出码 |
典型使用场景
- 应用报 403：直接以该 ServiceAccount 的身份试一次，确认是权限缺失还是别的问题
- 上线前自检：新增的 Role 写好之后先验证关键动作是否真的被授予
- 排错范围确认：用 --list 看当前身份掌握的全部规则，判断是不是绑错了角色
- 最小权限审计：定期抽查各 ServiceAccount 的实际权限，找出过宽的绑定
- 模拟他人身份：用 --as 复现用户反馈的权限问题，不必拿到对方凭据
常用命令
常用命令
kubectl auth can-i create pods -n prod # 当前身份在 prod 能否创建 Pod
kubectl auth can-i get secrets -q -n prod # 只看退出码，便于脚本判断
kubectl auth can-i --list -n prod # 列出当前身份的全部规则
kubectl auth can-i delete pods --as=system:serviceaccount:prod:builder -n prod
kubectl auth can-i '*' '*' --all-namespaces # 是否集群管理员级权限
kubectl auth can-i get pods --as=system:serviceaccount:prod:builder --as-group=system:masters结果读法
| 结果 | 含义 | 下一步 |
|---|---|---|
| yes | 判定允许 | 若实际仍报 403，检查是否用了别的身份或别的命名空间 |
| no | 判定拒绝 | 用 --list 与 rolebinding 对照，确认缺哪条规则 |
| -q 返回 0/1 | 只看结论 | 适合 CI 中断言权限配置 |
| --list 输出为空 | 该身份几乎没有权限 | 确认绑定是否漏建或绑到了别的命名空间 |
用 --as 模拟身份需要当前身份持有 impersonate 权限（集群管理员默认具备）。没有该权限时命令会报错而不是返回 no，因此拿到 no 之前先确认模拟是否真的生效。
can-i 只回答最终判定，不告诉你哪条规则生效。定位具体规则要用 --list 列出规则，再与 kubectl get rolebinding,clusterrolebinding -o wide 的结果对照，注意 ClusterRoleBinding 的作用范围是全集群。