使用Kopf构建的Kubernetes Operator遇RBAC权限报错如何排查

• 核对Operator Pod实际使用的ServiceAccount配置
  很多时候Deployment配置中serviceAccountName拼写错误、或未显式指定，会导致Pod默认使用default ServiceAccount而非预期的配置。可以执行以下命令验证：

  kubectl get pod <你的Operator Pod名称> -o jsonpath='{.spec.serviceAccountName}{"\n"}'
  

  如果输出不是exchangerates-operator，修改Deployment的ServiceAccount配置即可。
• 核对RBAC规则与CRD定义的一致性
  确认ClusterRole中配置的apiGroups、资源名称和CRD的实际定义完全匹配，无拼写错误：

  kubectl get crd exchangerates.operators.brennerm.github.io -o jsonpath='CRD资源名：{.spec.names.plural}{"\n"}API组：{.spec.group}{"\n"}'
  

  将输出和你配置的ClusterRole规则做对比，确保resources、apiGroups字段完全一致。
• 核对ClusterRoleBinding的绑定主体
  很多场景下ClusterRoleBinding的subjects配置中，ServiceAccount的命名空间、名称拼写错误会导致权限绑定失效：

  kubectl get clusterrolebinding <你的ClusterRoleBinding名称> -o jsonpath='绑定的SA名称：{.subjects[?(@.kind=="ServiceAccount")].name}{"\n"}绑定的SA命名空间：{.subjects[?(@.kind=="ServiceAccount")].namespace}{"\n"}'
  

  确保输出的SA名称、命名空间和你实际使用的system:serviceaccount:default:exchangerates-operator完全匹配。
• 在Operator Pod内部直接验证权限
  kubectl auth can-i的校验结果可能和Pod内实际请求有差异，直接用Pod内部挂载的ServiceAccount token调用API验证最准确：

  # 进入Operator Pod shell
  kubectl exec -it <你的Operator Pod名称> -- sh
  # 执行API请求验证
  TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
  CACERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
  curl --cacert $CACERT -H "Authorization: Bearer $TOKEN" https://kubernetes.default.svc/apis/operators.brennerm.github.io/v1/exchangerates
  

  如果请求返回403，说明RBAC规则确实存在问题；如果返回200，说明是Kopf配置问题，检查Kopf启动参数是否指定了非预期的kubeconfig、是否加了错误的--namespace/--namespaced参数限制了请求范围。
• 检查额外的准入控制策略拦截
  如果集群部署了OPA Gatekeeper、Kyverno等准入控制组件，可能存在额外的策略拦截了该ServiceAccount的请求，可查看kube-apiserver的对应请求日志，确认403的具体触发来源。

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