Kubernetes：如何排查ClusterRole权限过高的原因

问题背景 #

在GKE v1.23环境中配置了用于CI/CD的ClusterRole，预期仅赋予查看权限（或可选更新权限），但实际该角色绑定的ServiceAccount拥有创建、修改等超出配置的权限。

当前ClusterRole配置 #

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/managed-by: kubectl
    app.kubernetes.io/part-of: cluster-auth
  name: github-actions-ops
  namespace: default
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs:
      - "get"

ClusterRoleBinding配置 #

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    app.kubernetes.io/managed-by: kubectl
    app.kubernetes.io/part-of: cluster-auth
  name: github-actions-ops
subjects:
  - kind: ServiceAccount
    name: github-actions-ops
    namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: github-actions-ops

异常现象 #

该ServiceAccount实际拥有远超配置的权限，测试结果如下：

$ kubectl config get-contexts
CURRENT   NAME                                                   CLUSTER                                                AUTHINFO                 NAMESPACE
*         DEV-NAME                                               DEV-NAME                                               github-actions-ops-dev   
          PRD-NAME                                               PRD-NAME                                               github-actions-ops-prd
$ kubectl auth can-i patch deploy --as=system:serviceaccount:default:github-actions-ops --namespace default
yes
$ kubectl auth can-i create service --namespace default
yes

排查步骤 #

• 检查ServiceAccount的所有权限绑定
  Kubernetes RBAC权限是累加的，只要ServiceAccount被绑定到其他高权限角色，就会获得额外权限。执行以下命令查看该ServiceAccount的所有ClusterRoleBinding和RoleBinding：

  kubectl get clusterrolebindings,rolebindings --all-namespaces -o json | jq '.items[] | select(.subjects[]? | .kind == "ServiceAccount" and .name == "github-actions-ops" and .namespace == "default")'
  

  重点排查是否绑定了cluster-admin、admin这类高权限预设角色。

• 验证ClusterRole的实际生效规则
  确认当前ClusterRole的配置是否正确应用，避免存在同名角色覆盖的情况：

  kubectl get clusterrole github-actions-ops -o yaml
  

  核对输出的rules部分，确保只有get verb，无额外的create、patch等权限。

• 排查GKE附加组件或IAM映射权限
  GKE部分附加组件（如Workload Identity）或IAM角色映射可能会自动给ServiceAccount添加权限。检查是否通过GKE IAM绑定了roles/container.admin这类高权限角色，这类角色会直接映射为Kubernetes的集群级权限。

• 用--verbose参数定位权限来源
  执行带--verbose的can-i命令，查看具体是哪个角色赋予了超出预期的权限：

  kubectl auth can-i patch deploy --as=system:serviceaccount:default:github-actions-ops --namespace default --verbose
  

  输出会明确显示允许操作的角色来源，直接定位问题根源。

• 检查聚合ClusterRole的影响
  部分ClusterRole通过aggregationRule自动聚合权限，若当前ClusterRole被包含在聚合规则中，可能会被追加额外权限：

  kubectl get clusterroles -o yaml | grep -A 10 "aggregationRule"
  

  确认是否有聚合规则包含了github-actions-ops角色。

• 验证操作上下文的正确性
  确认执行命令时使用的上下文是否正确，避免误操作到其他集群或使用了错误的身份认证：

  kubectl config current-context
  

  对比上下文的AUTHINFO与测试命令中--as指定的ServiceAccount是否一致。

内容的提问来源于stack exchange，提问作者Silver Flash