Kubernetes RBAC：角色与集群角色绑定

理解 Role、ClusterRole 与两种绑定的权限范围

Kubernetes 的 RBAC 机制通过四种核心对象实现权限控制：Role、ClusterRole、RoleBinding 和 ClusterRoleBinding。Role 与 ClusterRole 仅负责定义权限规则，不包含授权对象。Role 的作用域严格限定在单个命名空间内，适用于管理该空间下的 Pod、Service 等资源；ClusterRole 则是集群级别对象，可定义跨命名空间资源（如 Node、PV）或所有命名空间内同类资源的权限。绑定对象负责将角色授予主体（User、Group 或 ServiceAccount）。关键区别在于：RoleBinding 仅在所在命名空间生效，即使它引用了 ClusterRole，其权限范围仍被限制在该命名空间内；而 ClusterRoleBinding 则无视命名空间边界，将权限直接赋予集群全局。理解这一边界是避免越权或授权失败的前提。

创建角色并完成 RoleBinding 与 ClusterRoleBinding

以授予用户只读 Pod 权限为例，首先定义角色。命名空间级 Role 的 YAML 中，rules 指定 apiGroups 为空字符串、resources 为 pods、verbs 包含 get、list、watch。若需集群级只读，则将 kind 改为 ClusterRole 并移除 metadata.namespace。授权阶段，RoleBinding 的 subjects 填写目标用户或 ServiceAccount，roleRef 必须严格匹配 apiGroup 为 rbac.authorization.k8s.io、kind 为 Role 或 ClusterRole 及对应 name。执行 kubectl apply 命令应用配置即可生效。若使用 ClusterRoleBinding，其 roleRef.kind 应为 ClusterRole，且无需指定命名空间。注意 subjects 中 ServiceAccount 的 namespace 字段不可省略，否则默认指向 default 空间，极易导致绑定失效。

验证授权结果与定位权限问题

配置完成后，必须通过 kubectl auth can-i 进行精准验证。例如，以指定用户身份检查当前命名空间权限：kubectl auth can-i list pods --as=dev-user -n dev。若需验证跨命名空间或集群权限，可添加 --all-namespaces 或指定非当前空间。若返回 yes 说明授权成功，no 则需排查。排障时，先使用 kubectl get rolebinding -n 命名空间 和 kubectl get clusterrolebinding 确认绑定是否存在且指向正确角色。接着检查 roleRef 是否拼写错误，以及 subjects 中的 name 是否与认证系统完全一致。通过配置 YAML、应用绑定、模拟请求验证的闭环，可快速定位权限拦截点，避免盲目修改策略。

常见坑与最小权限实践

RBAC 实践中最常见的坑是混淆绑定范围：误以为 RoleBinding 引用 ClusterRole 即可全局生效，实际仍受命名空间限制；反之，滥用 ClusterRoleBinding 会导致权限溢出，例如将普通开发者的 RoleBinding 升级为 ClusterRoleBinding，可能意外赋予其操作其他业务命名空间的权限。此外，roleRef 一旦创建便不可直接修改，必须删除重建；subjects 中若混淆 User 与 ServiceAccount 类型，或遗漏 namespace 字段，均会导致静默失败。严禁直接绑定 cluster-admin 给日常账号。应遵循最小权限原则：优先使用 Role 限定空间，复用 ClusterRole 定义标准权限集，并通过 RoleBinding 按需下发，确保权限可审计、可回收。