kubernetes rbac配置核心是定义“谁”在“什么范围”能“做什么”，通过role/clusterrole定义权限、rolebinding/clusterrolebinding绑定主体，规则需明确apigroups、resources和verbs，遵循最小权限原则。
配置 Kubernetes RBAC 权限，核心是定义「谁（Subject）」在「什么范围（Namespace 或集群级）」能「做什么（API 操作）」。不需要改集群配置，全靠 YAML 资源对象动态管理，关键在于选对对象类型、写清规则、绑定准确。
Role 和 ClusterRole：先定权限范围
权限规则本身由 Role 或 ClusterRole 定义，区别只在作用域：
-
Role：只管单个命名空间里的资源，比如
deployments、pods、services。必须指定namespace字段。 -
ClusterRole：可定义集群级资源（如
nodes、clusterroles）权限，也能用于命名空间内资源——只要后续用 RoleBinding 绑定它，权限就自动“降级”到该命名空间。
示例：一个只读查看 Pod 日志的 Role
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-logger namespace: default rules: - apiGroups: [""] resources: ["pods/log"] verbs: ["get"]
RoleBinding 和 ClusterRoleBinding：再绑具体对象
有了角色，得告诉 Kubernetes “谁拥有这个角色”。绑定对象决定了 Subject 类型和生效范围：
- RoleBinding：绑定到当前命名空间内的用户、组或 ServiceAccount。即使绑定的是 ClusterRole，权限也只在本命名空间生效。
- ClusterRoleBinding：绑定到整个集群，适用于需要全局权限的对象，比如监控系统查所有节点，或管理员账号。
示例：把上面的 pod-logger 角色，授予 default 命名空间下的服务账户 log-reader
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pod-logs namespace: default subjects: - kind: ServiceAccount name: log-reader namespace: default roleRef: kind: Role name: pod-logger apiGroup: rbac.authorization.k8s.io
权限规则怎么写才安全有效
Rules 是 RBAC 的权限核心，每条规则需明确三要素：
-
apiGroups：API 组名，空字符串
""表示核心 API（如 pods、nodes），"apps"对应 Deployments，"batch"对应 Jobs。 -
resources：资源类型，支持复数形式（
pods）、子资源（pods/log、pods/exec），也可用["*"]（慎用）。 -
verbs：允许的操作，常见有
get、list、create、delete、update、watch。不要给["*"]，除非是 cluster-admin 级别。
小技巧：用 kubectl auth can-i 验证权限是否生效，比如：
kubectl auth can-i list pods --as=system:serviceaccount:default:log-reader -n default
生产环境几个实用建议
避免踩坑，提高可维护性：
- 不直接绑定真实用户（User），优先用 Group 或 ServiceAccount —— 用户身份通常由外部 IDP（如 OIDC）管理，RBAC 只认名字，不负责认证。
- 按最小权限原则设计角色：开发人员不需要删 node，CI/CD 账号不需要看 secrets，每个角色只含必要 verbs + resources。
- 集群级只读角色推荐复用官方
viewClusterRole；敏感操作（如deletecollection、patch）单独评估是否开放。 - 定期审计：运行
kubectl get rolebindings,clusterrolebindings --all-namespaces -o wide查看谁绑了什么，配合kubectl auth can-i --list检查实际权限。
