K8s测试RBAC指定resourceName权限时kubectl auth can-i命令报错

你遇到的问题由命令使用错误和RBAC配置本身错误两部分共同导致：

• 首先是kubectl auth can-i命令格式错误：该命令的位置参数仅接收「动词、资源类型」两个值，指定目标资源名不能直接作为第三个位置参数传入，必须通过显式的--resource-name参数声明。你直接把dark-blue-app跟在pod后面传位置参数，kubectl无法识别参数含义，就会抛出参数数量不符合要求的报错。
• 其次是现有RBAC配置存在3个明显问题，就算命令格式写对，权限校验也无法得到符合预期的结果：
  1. 命名空间不匹配：命名空间级Role和绑定它的RoleBinding必须位于同一个命名空间才能生效。你的developer Role创建在blue命名空间下，但dev-user-binding RoleBinding却创建在default命名空间下，跨命名空间的绑定对命名空间级Role完全无效。
  2. 模拟测试的主体错误：你的RoleBinding绑定的用户是dev-user，但第一次执行校验命令时--as参数写的是developer（这是Role的名字，不是被授权的用户名），之前返回的YES结果完全不具备参考价值。
  3. Role授权的动词不匹配：你当前developer Role的规则里，只给pods资源配置了list、create、delete三个动词，根本没有包含get，就算其他配置都对，校验get权限也会返回NO。另外要注意：list是集合级操作，请求不会携带单个资源名，给带resourceName限定的规则配置list动词是无效的，用户无法通过该规则获得pod列表的查看权限。

1. 先修正RBAC配置错误：
   • 将dev-user-binding RoleBinding的命名空间改为blue，和待绑定的developer Role保持同命名空间。
   • 根据实际需求调整Role的verbs列表：如果需要用户获取单个dark-blue-app pod的详情，就添加get动词；如果需要用户能列出blue命名空间下所有pod，就删除规则里的resourceName限定，否则list权限不会生效。
2. 使用正确的命令格式执行校验，注意必须通过--resource-name指定目标资源，同时--as参数要传入正确的被授权用户名：

# 校验dev-user是否有get blue命名空间下dark-blue-app pod的权限
kubectl auth can-i get pods -n blue --as dev-user --resource-name dark-blue-app

# 校验delete权限示例
kubectl auth can-i delete pods -n blue --as dev-user --resource-name dark-blue-app

如果配置正确，上述命令会返回对应权限的校验结果YES/NO。

内容的提问来源于stack exchange，提问作者pedro_bb7