client-go默认无权限是因为其不处理RBAC，仅转发请求，权限取决于Pod绑定的ServiceAccount及对应RoleBinding；需通过RBAC配置最小必要权限并验证token挂载与命名空间一致性。
为什么 client-go 创建的 client 默认没权限？
因为 Kubernetes 的 RBAC 是服务端强制校验机制，client-go 本身不带任何权限逻辑 —— 它只是把你的请求原样发过去，能不能过，全看集群里有没有对应的 Role、RoleBinding 或 ClusterRoleBinding。你用 rest.InClusterConfig() 拿到的 token，背后是 Pod 的 ServiceAccount，而这个 SA 默认只有极小范围权限（甚至可能什么都没有）。
- 本地
kubectl能操作 ≠client-go程序能操作：kubectl通常用的是你本地 kubeconfig 里的用户凭据，而 Pod 内运行的程序用的是挂载进来的 SA token - 报错常见形式：
Forbidden: User "system:serviceaccount:default:my-app" cannot list resource "pods" in API group "" in the namespace "default" - 别急着改代码，先确认 SA 绑定关系：
kubectl get sa my-app -n default→kubectl get rolebinding -n default | grep my-app
怎么给 ServiceAccount 分配最小必要权限？
RBAC 的核心原则是「按需授权」，不是给 cluster-admin 一了百了。实际开发中，多数 Operator 或控制器只需要读/写某几个资源的子集（比如只 watch ConfigMap，只 patch 自己管理的 Deployment 的 annotation）。
- 用
Role+RoleBinding限定命名空间内权限；跨 ns 或集群级操作才用ClusterRole+ClusterRoleBinding -
rules里明确写apiGroups（如""表示 core v1，"apps"表示 apps/v1），不能留空或写错大小写 - 避免用
resources: ["*"]，优先列具体资源名；verbs只开需要的，比如["get", "list", "watch"]就够 controller 同步状态 - 示例片段（绑定到
my-appSA）：apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: my-app-reader namespace: default rules: - apiGroups: [""] resources: ["pods", "configmaps"] verbs: ["get", "list", "watch"]
client-go 初始化时如何确保用对 ServiceAccount？
初始化 client 的方式直接决定了它用哪个身份访问 API Server。Pod 内运行和本地调试场景不同，配置路径也不同，容易混淆。
- 在集群内运行：必须用
rest.InClusterConfig()，它会自动读取/var/run/secrets/kubernetes.io/serviceaccount/下的token和ca.crt，不用手动指定证书 - 本地调试：不能依赖
InClusterConfig，得用clientcmd.BuildConfigFromFlags("", kubeconfigPath)，且该 kubeconfig 对应的 user 必须有对应权限（否则报错一样） - 注意
rest.Config的Host字段：InCluster 场景下它会是https://kubernetes.default.svc，如果被意外覆盖成 localhost 或其他地址，请求根本发不到 API Server - 验证是否生效：初始化 client 后，用
clientset.CoreV1().Pods("default").List(ctx, metav1.ListOptions{})做一次轻量探测，捕获errors.IsForbidden判断权限问题
为什么加了 RBAC 还是 403？几个高频盲区
权限配置看似写对了，但常因环境细节或 YAML 格式问题导致不生效，这类问题排查成本高，但原因很固定。
立即学习“go语言免费学习笔记（深入）”；
- ServiceAccount 名字拼错：
RoleBinding.subjects[].name必须严格匹配ServiceAccount的 metadata.name，大小写、中划线都不能差 - Namespace 不一致：
RoleBinding和ServiceAccount必须在同一个 namespace；Role和RoleBinding也必须同 namespace；但ClusterRoleBinding绑定的ServiceAccount可以跨 namespace - Token 挂载失败：检查 Pod spec 中是否设置了
automountServiceAccountToken: true（默认为 true，但若显式设为 false 就不会挂载） - API Group 版本不匹配：比如用
apps/v1的Deployment，但Role.rules.apiGroups写成了["extensions"]（已弃用）
最省事的验证方式：进 Pod 执行 curl -k -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kubernetes.default.svc/api/v1/namespaces/default/pods，看返回是不是 200 或明确的 403 —— 这能绕过 client-go 层，直击 RBAC 校验结果。
