Go程序在Kubernetes中因403报错，主因是RBAC权限配置错误：需检查ServiceAccount、Role/ClusterRole、RoleBinding是否漏配、写错或跨namespace绑定，且须确保automountServiceAccountToken:true、apiGroups/resources/verbs匹配，并用rest.InClusterConfig()加载凭据。
Go 程序在 Kubernetes 中跑不起来，八成不是代码写错了，而是 RBAC 权限没配对——403 Forbidden 错误几乎全是它干的。别急着改 Go 逻辑，先检查 ServiceAccount、Role/ClusterRole、RoleBinding 这三样有没有漏、写错、跨 namespace 绑错。
ServiceAccount 必须显式创建，不能依赖 default
Pod 默认用 default ServiceAccount，但它在大多数集群里是“裸奔”状态：没 token、没挂载、没任何 RBAC 授权。本地 kubectl 能通，是因为你用的是个人 kubeconfig；进 Pod 就 403，是因为 rest.InClusterConfig() 拿的是 Pod 内 ServiceAccount 的身份。
- 为每个应用单独建
ServiceAccount，YAML 中明确指定apiVersion: v1和kind: ServiceAccount - 避免跨 namespace 使用——
ServiceAccount天然绑定 namespace，namespace: monitoring的 SA 无法操作default下的Pod - K8s 1.24+ 默认不自动挂载 token，如需 API 访问，必须在 Pod spec 中显式设
automountServiceAccountToken: true（或留空，默认 true）
Role 和 RoleBinding 必须同 namespace，且 verbs/resource/apiGroups 对得上
Role 只作用于单个 namespace，它的 RoleBinding 也必须定义在同一个 namespace 下，否则权限不会生效。常见错误是把 RoleBinding 创建在 default，而目标 Role 在 my-app，结果白配。
-
apiGroups别写错：核心资源（pods,services）用""（空字符串），不是"core"或"*"；networkpolicies属于"networking.k8s.io"，ingresses也是 -
resources名称要跟kubectl api-resources输出一致，比如是"networkpolicies"（复数），不是"networkpolicy" -
verbs列表必须包含实际调用的操作：用clientset.NetworkingV1().NetworkPolicies(ns).Create()就至少要["create"]；若还做List或Delete，对应加"list"、"delete"
Go 代码里用 rest.InClusterConfig() 才能正确加载 SA 凭据
别自己读 /var/run/secrets/kubernetes.io/serviceaccount/token 拼 header，也别硬编码 kubeconfig 路径——这些在 Pod 里要么失败，要么绕过 RBAC 校验逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 调用
rest.InClusterConfig()自动读取 token、CA 证书和 namespace，返回的*rest.Config已带完整认证上下文 - 用该 config 初始化 clientset：
clientset := kubernetes.NewForConfig(config)，后续所有 client 操作都走这个身份 - 如果程序既跑集群内又跑本地，建议用环境变量开关：
if os.Getenv("KUBERNETES_SERVICE_HOST") != ""判断是否 in-cluster，再选InClusterConfig或BuildConfigFromFlags
验证权限最简单的方法是 kubectl auth can-i
别等 Go 程序报错才排查，用 kubectl 直接模拟 SA 权限，比翻文档快十倍。
- 查当前 context 是否有权限：
kubectl auth can-i list pods -n my-app - 查指定 SA：
kubectl auth can-i create networkpolicies --as=system:serviceaccount:my-app:my-app-sa -n my-app - 列出所有权限：
kubectl auth can-i --list --as=system:serviceaccount:my-app:my-app-sa -n my-app - 注意：SA 名字格式固定为
system:serviceaccount:<ns>:<name>，少一个冒号或拼错 namespace 都会查不到
最容易被忽略的一点：RBAC 规则是“拒绝优先”，但策略本身不叠加——RoleBinding 绑定多个 Role 是允许的，但每个 Role 的 rules 是独立校验的；而跨 namespace 的资源访问（比如从 my-app 查 monitoring 的 Secret），必须用 ClusterRole + ClusterRoleBinding，光靠 Role 不行。
