Kubernetes RBAC 模型由哪些对象组成，如何排查权限问题？

结论：RBAC 由四类对象组成：Role/ClusterRole 定义权限（对什么资源做什么操作），RoleBinding/ClusterRoleBinding 把权限授予主体（User、Group、ServiceAccount），权限模型是纯白名单，只有 allow 没有 deny。

展开：Role+RoleBinding 作用于单个命名空间，ClusterRole 既可配 ClusterRoleBinding 授权集群级资源（node、PV、namespace），也可被 RoleBinding 引用实现命名空间内权限复用。动词包括 get/list/watch/create/update/patch/delete，资源可细到 resourceName 级别（只允许操作某个具名对象）。Pod 默认用 default ServiceAccount 访问 API，生产应为每个应用建专用 SA 并按最小权限授权，设置 automountServiceAccountToken: false 避免不必要挂载。排查三板斧：1）kubectl auth can-i <verb> <resource> --as system:serviceaccount:ns:name 直接验证某主体权限；2）kubectl describe rolebinding/clusterrolebinding 找绑定关系；3）API Server 审计日志定位 403 来源。经典坑：1）list 权限不能用 resourceName 限制；2）aggregated ClusterRole（aggregationRule）会被 admin/edit 等内置角色自动合并，排查时容易漏看；3）多绑定权限是并集，角色之间不存在互相否决。