01
写明命名空间
离线清单中的 Role 和 RoleBinding 需要明确的 metadata.namespace。RoleBinding 引用 ClusterRole 时，也只在自身命名空间授予权限。
Kubernetes
Kubernetes RBAC 可视化从主体追到每条规则
粘贴带命名空间的角色与绑定清单，准备好后再手动分析。
Kubernetes RBAC 可视化
授权路径与发现
粘贴 RBAC 清单后开始分析。
清单只在浏览器内处理；不连接集群，也不发送网络请求。
查询一项授权
用 * 表示集群范围；只看关系图时可留空查询字段。
粘贴清单开始。
审查权限时，单看 Role 很难知道谁最终获得了它。Kubernetes RBAC 可视化把主体、绑定、角色与规则串起来，让代码评审能看见授权是从哪里来的。
这份 Kubernetes RBAC 可视化结果只覆盖你提供的清单。它不知道集群里的默认角色、用户所属的组或其他鉴权器，因此把缺失证据标出来，而不代替线上鉴权判断。
为什么使用 Kubernetes RBAC 可视化？
看清来源，也看清资料缺口。
每条授权都有来路
RBAC 权限图按 User、Group、ServiceAccount 展开到 RoleBinding、ClusterRole 与具体规则。RoleBinding 即使引用 ClusterRole，授权范围仍是绑定所在的命名空间。 集群角色绑定则可能授予集群范围。
潜在权限有具体出处
权限分析只对已绑定到主体的规则标记通配符、Secrets 读取与权限提升动词。找不到引用角色或聚合角色成员时另列资料不完整，不把未知结果写成拒绝。
先核对范围，再读查询结果
02
分清主体种类
按 User、Group 或带命名空间的 ServiceAccount 选主体。工具不会从用户名猜测组成员，两个同名的服务账号也不会合并。
03
留意具名资源
规则带 resourceNames 时，查询必须填写资源名；list/watch 还依赖匹配的字段选择器，此处无法替真实请求验证。
从授权路径到潜在权限报告
可追溯的关系图
RoleBinding 权限分析按主体 → 绑定 → 角色 → 规则展示路径。点选节点即可聚焦关联授权，同时保留命名空间与 API 组。
按资源与动词核对
Kubernetes 权限查询同时检查主体、范围、API 组、资源或子资源、动词以及可选资源名；pods 与 pods/exec 不会混为一谈。
可导出的审查记录
Kubernetes RBAC 可视化报告列出宽泛通配、Secrets 读取、bind/escalate/impersonate 等信号，并附上触发的绑定与规则。
静态清单能回答到哪里
- 不预测线上授权
- 本工具不连接集群，也不调用 SubjectAccessReview。清单里没找到匹配规则，不等于线上请求一定被拒绝。
- 缺失关系不补造
- 引用的角色缺席或聚合 ClusterRole 成员不全时，报告标记不完整；User 与 Group 的成员关系也不会凭名称推断。
- 只核对资源规则
- nonResourceURLs 会保留为未评估提示。工具不发现自定义资源的实际作用域，不生成或应用策略，也不会把 pods 权限扩展成 pods/exec。
Kubernetes RBAC 可视化常见问题
为什么 RoleBinding 在当前命名空间有效，却不能访问全部命名空间？
RoleBinding 只在自身命名空间生效，即使它引用的是 ClusterRole。要授予全局范围，需要 ClusterRoleBinding；图中会分别标明。
一个 ServiceAccount 能关联多个 RoleBinding 吗？
能。RBAC 授权是累加的，工具分别保留每条绑定来源，不会只选一个“最终角色”。
有 Secrets 的 list 权限就能看到内容吗？
list 响应可能包含 Secret 对象及其数据，即便没有单个对象的 get 权限。若规则限制了 resourceNames，list/watch 还需要相应字段选择器。
某命名空间的 ServiceAccount 能读取另一命名空间的 Secret 吗？
目标命名空间的 RoleBinding 可以引用其他命名空间的 ServiceAccount。输入应写明该主体的 namespace，避免把同名账号混在一起。
Kubernetes RBAC 能明确写“拒绝”规则吗？
不能。RBAC 只累加允许规则；本页只能找到所贴清单中的授权路径，无法给出线上最终的允许或拒绝结论。
还有权限问题？