4. RBAC核心对象：RoleBinding与ClusterRoleBinding的定义、绑定机制与作用范围

在Kubernetes RBAC体系中，RoleBinding和ClusterRoleBinding是连接“主体”（User/Group/ServiceAccount）与“权限”（Role/ClusterRole）的桥梁。审计控制平面RBAC时，这两个对象的配置直接决定了权限是否被正确、安全地授予。

4.1 定义与核心区别

4.2 绑定机制与YAML结构

两种Binding的YAML结构高度相似，核心差异在于 roleRef 的 kind 字段和 subjects 的配置。

4.2.1 RoleBinding示例（命名空间级）

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-reader-binding
  namespace: development
subjects:
- kind: User
  name: "alice@example.com"
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: dev-sa
  namespace: development
roleRef:
  kind: ClusterRole      # 引用集群级别的ClusterRole
  name: view             # 但权限被限制在development命名空间
  apiGroup: rbac.authorization.k8s.io

4.2.2 ClusterRoleBinding示例（集群级）

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
subjects:
- kind: User
  name: "ops-admin@company.com"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin    # 授予整个集群的管理员权限
  apiGroup: rbac.authorization.k8s.io

4.3 作用范围与权限传播机制

下图展示了RoleBinding与ClusterRoleBinding在集群中的权限作用范围差异：

4.4 审计检查清单

• 检查ClusterRoleBinding的subjects：确认没有将cluster-admin或其他高危ClusterRole绑定到非管理员用户、组或ServiceAccount。
• 检查RoleBinding引用的ClusterRole：当RoleBinding引用ClusterRole时，确认该ClusterRole的规则不会因“降级绑定”而产生意外效果（例如，包含get secrets的ClusterRole被绑定到开发命名空间）。
• 检查跨命名空间的ServiceAccount绑定：RoleBinding的subjects中如果引用其他命名空间的ServiceAccount，需确认该跨命名空间访问是否经过审批。
• 检查聚合ClusterRole的绑定：通过aggregationRule聚合的ClusterRole被绑定时，其权限会动态变化，审计时需结合当前集群中所有匹配的ClusterRole进行综合评估。

# 列出所有ClusterRoleBinding
kubectl get clusterrolebindings.rbac.authorization.k8s.io -o wide

# 查看特定ClusterRoleBinding的详细YAML
kubectl get clusterrolebinding cluster-admin-binding -o yaml

# 检查所有绑定到cluster-admin的ClusterRoleBinding
kubectl get clusterrolebindings.rbac.authorization.k8s.io -o json | jq '.items[] | select(.roleRef.name=="cluster-admin") | {name: .metadata.name, subjects: .subjects}'

4.5 安全基线建议