ServiceAccount是Kubernetes中专为Pod内进程设计的命名空间级身份标识，区别于人工使用的User Account；它自动关联Secret（含token、ca.crt等），通过RBAC绑定权限，并由InClusterConfig在Go程序中安全加载以调用API。
ServiceAccount 是什么，和用户账号有什么区别
ServiceAccount 是 Kubernetes 中专为 Pod 内运行的进程设计的身份标识，不是给人用的。它绑定到命名空间，由 Kubernetes 自动创建（如 default），也可手动定义。和管理员用的 User Account 不同，ServiceAccount 有对应的 Secret（含 token、ca.crt、namespace），能被挂载进容器，供应用调用 API Server。
如何创建自定义 ServiceAccount 并限制作用范围
默认的 default ServiceAccount 权限极低（通常没任何 RBAC 权限），但很多 Helm Chart 或部署模板会直接用它，容易引发权限混乱。推荐为每个应用单独建 ServiceAccount，并限定在所属命名空间内：
- 用 YAML 创建：指定 apiVersion: v1 和 kind: ServiceAccount，不填 namespace 则默认在当前命名空间
- 避免跨命名空间使用——ServiceAccount 无法跨 ns 访问资源，这是天然隔离边界
- 不要手动修改 auto-generated token Secret；K8s 1.24+ 已弃用自动挂载 token，需显式设置 automountServiceAccountToken: false 关闭（除非真需要）
如何通过 RBAC 绑定 ServiceAccount 和权限
ServiceAccount 本身没权限，必须靠 RBAC（Role / ClusterRole + RoleBinding / ClusterRoleBinding）赋权。关键原则是：最小权限、命名空间隔离、避免用 ClusterRoleBinding 除非必要。
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 在目标命名空间定义 Role（例如只允许读取本 ns 的 Pods）
- 用 RoleBinding 将该 Role 绑定到你的 ServiceAccount（subjects 中指定 kind: ServiceAccount、name 和 namespace）
- 若需跨 ns 操作（如 Operator 场景），才考虑 ClusterRole + ClusterRoleBinding，并严格限制 resources 和 verbs
- Golang 程序中加载 kubeconfig 时，可用 rest.InClusterConfig() 自动读取 pod 内挂载的 ServiceAccount token，无需硬编码凭证
在 Go 程序里安全使用 ServiceAccount 调用 Kubernetes API
Pod 启动后，Kubernetes 会把 ServiceAccount 的 token 和 CA 证书挂载到 /var/run/secrets/kubernetes.io/serviceaccount/。Golang 客户端可直接利用：
立即学习“go语言免费学习笔记（深入）”；
- 调用 rest.InClusterConfig() —— 它会自动读取 token 文件、CA 文件和 namespace，构造出带认证的 rest.Config
- 用该 config 初始化 clientset（如 kubernetes.NewForConfig()），后续所有 client 操作都自带身份和权限上下文
- 别自己读 token 去拼 Authorization header；InClusterConfig 已处理好 bearer token、TLS 验证、重试等细节
- 开发调试阶段，可用 kubectl --token=xxx --certificate-authority=ca.crt --server=https://... proxy 本地代理，让 Go 程序连 localhost:8001，避开证书校验问题
基本上就这些。ServiceAccount 管理不复杂，但容易忽略自动挂载、RBAC 绑定范围和 InClusterConfig 的正确使用——这三处出错，最常导致 “Forbidden” 或 “Unauthorized” 错误。
