GKE上Spring Cloud Kubernetes选主所需RBAC规则与权限排查

你的Spring Cloud Kubernetes选主功能无法触发OnGrantedEvent，核心原因是RBAC权限配置存在聚合动词覆盖不足的问题，结合Spring Cloud Kubernetes 3.0.2 Leader选举的工作原理，以下是具体修复点：

1. 补充ConfigMap的update和patch权限 #

你在configmap-editor Role中使用了聚合动词write，虽然K8s定义write包含create和update，但在严格权限集群中，聚合动词可能无法完全覆盖选举过程中需要的部分字段更新（如ConfigMap的ownerReference、annotation），需要明确添加update和patch权限：

修改后的configmap-editor Role：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: configmap-editor
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch", "create", "delete", "update", "patch"]

2. 精简Pod权限（可选） #

你的pod-viewer Role配置了get, list, watch，而Spring Cloud Kubernetes Leader选举仅需要Pod的get权限（用于获取当前Pod的元数据，作为ConfigMap的ownerReference），多余的list和watch可以保留但并非必须。

3. 额外排查点 #

• 确认Pod的serviceAccountName已正确设置为my-app，确保RoleBinding的权限能正确作用到Pod
• 查看应用运行时日志（而非仅启动日志），是否存在Forbidden或PermissionDenied的权限错误（选举过程中的权限问题可能不会在启动时抛出）
• 检查Workload Identity关联的GCP服务账号是否未限制K8s API访问（当前仅配置Cloud Trace Agent权限不影响K8s内部RBAC，但需确保GCP侧未拦截K8s API请求）

原理说明 #

Spring Cloud Kubernetes Leader选举基于ConfigMap实现分布式锁：

1. 应用启动后会尝试创建/更新指定的锁ConfigMap（默认名称spring-cloud-kubernetes-leader）
2. 成功获取锁的实例会将自身Pod的元数据写入ConfigMap的ownerReference，并触发OnGrantedEvent
3. 过程中需要对ConfigMap执行完整的读写更新操作，以及读取自身Pod的元数据权限

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