1. 从一次误删事故说起：为什么 ServiceAccount 和 RBAC 必须认真配
很多刚接触 Kubernetes 的朋友，第一次把应用跑起来之后，注意力全在 Deployment 和 Service 上，权限这块基本靠默认值撑着。我见过一个挺典型的场景：团队里有个同学为了图省事，把 Dashboard 的管理员 Token 直接贴到了内部 Wiki 上，结果某个测试环境的脚本拿着这个 Token 把生产命名空间里的 Service 全删了。事后复盘发现，那个 Token 绑的是cluster-admin，权限大到没边。
这个问题的根子不在 Dashboard，而在于我们从来没认真想过：谁在什么范围内、对哪些资源、能做哪些动作。Kubernetes 给出的答案就是 ServiceAccount 加 RBAC。ServiceAccount 解决的是"Pod 里的程序以什么身份说话"，RBAC 解决的是"这个身份被允许做什么"。两者配合，才能把权限边界划清楚。
这篇内容聚焦的是落地配置，不是概念科普。我会围绕 Service、Ingress、Dashboard 管理插件这几个高频场景，把 ServiceAccount 创建、Role/ClusterRole 定义、RoleBinding 绑定、以及用kubectl auth can-i验证的完整链路走一遍。你跟着做，能拿到一套可以直接复制进集群的 YAML 清单，也能学会怎么判断一个权限到底给大了还是给小了。
适合谁看：已经能跑起 K8s 集群、会写基础 YAML、但对权限模型还停留在"能用就行"阶段的开发和运维同学。如果你正在做多租户隔离、CI/CD 机器人权限收敛、或者 Dashboard 安全加固，这篇的配置可以直接拿去改。
先说清楚一个容易混淆的点。ServiceAccount 是命名空间级别的资源，Pod 默认会挂载default这个 SA。而 RBAC 的 Role 也是命名空间级别，ClusterRole 是集群级别。绑定关系里，RoleBinding 可以把 Role 或 ClusterRole 绑给某个 SA，但作用范围只在该命名空间内；ClusterRoleBinding 则是全集群生效。这个区别决定了你写 YAML 时到底该用哪个 kind，后面每个场景我都会点明。
另外提一句，权限最小化不是一次配完就完事，它需要配合审计动作。kubectl auth can-i就是最轻量的审计工具，能让你在不真正执行操作的前提下，问一句"这个身份能不能干这件事"。这个命令我会在每个场景里都用上，你最好也养成习惯。
2. TaoToken 前置准备：把模型接入和集群权限串起来
在正式写 RBAC 之前，我想先聊一个实际工作中经常被忽略的环节：当你的集群里跑着 AI 相关的 Operator、Agent 或者自研的模型调用服务时，这些组件同样需要 ServiceAccount 和权限。而它们调用的模型服务，如果走的是统一网关，配置方式会和普通应用不太一样。
我最近在几个项目里用的是 TaoToken 作为模型调用的统一入口。它的定位是把多家模型的 API 收敛成一个兼容接口，这样集群里的服务不用为每个模型单独维护 Key 和地址。官网在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 入口是 https://taotoken.net/api 。对于 K8s 场景来说，比较实用的点是它支持把配置写进环境变量或者 Secret，然后通过 ServiceAccount 关联的 Pod 去读取。
这里要强调一个安全原则：模型 API Key 绝对不能硬编码在 Deployment 的 env 里明文暴露。正确做法是放进 Secret，再通过envFrom或者 volume 挂载给 Pod。而 Pod 用哪个 ServiceAccount，决定了它能访问哪些 Secret（如果启用了 Secret 的 RBAC 控制）。所以模型接入和集群权限这两件事，在真实项目里是连在一起的。
具体到操作层面，你可以先在 TaoToken 的控制台创建一个 API Key，地址是 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite 。拿到 Key 之后，不要直接写进 YAML，而是用kubectl create secret创建：
kubectl create secret generic taotoken-secret \ --from-literal=api-key='你的Key' \ -n your-namespace然后在 Deployment 里引用：
apiVersion: apps/v1 kind: Deployment metadata: name: ai-agent namespace: your-namespace spec: replicas: 1 selector: matchLabels: app: ai-agent template: metadata: labels: app: ai-agent spec: serviceAccountName: ai-agent-sa containers: - name: agent image: your-agent:latest env: - name: TAOTOKEN_API_KEY valueFrom: secretKeyRef: name: taotoken-secret key: api-key - name: TAOTOKEN_BASE_URL value: "https://taotoken.net/api"注意这里serviceAccountName指向的ai-agent-sa就是我们要创建的专用 SA，而不是默认的default。为什么要专门建一个？因为默认 SA 在很多集群里权限过大，而且所有没指定 SA 的 Pod 都共用它，一旦某个 Pod 被攻破，攻击面会扩散。专用 SA 配合最小权限 Role，能把爆炸半径控制住。
如果你用的是 Claude Code 这类编码工具，或者想通过 coding-plan 的方式管理长期任务，TaoToken 也提供了对应的入口：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite 。这些工具在集群里跑的时候，同样建议用独立 SA 隔离。
前置准备做到这里就够了：一个 API Key、一个 Secret、一个待创建的 SA 名字。接下来进入正题，开始写 RBAC。
3. 可复制配置：Service、Ingress、Dashboard 三套 RBAC 清单
这一节是全文的核心，我会给出三套完整的 YAML，分别对应 Service 管理、Ingress 管理、Dashboard 管理插件。每套都包含 ServiceAccount、Role 或 ClusterRole、以及绑定关系。你可以直接复制到文件里kubectl apply。
先说一个通用原则：能用 Role 就不用 ClusterRole，能用 RoleBinding 就不用 ClusterRoleBinding。Role 只在单个命名空间生效，权限天然被限制住；ClusterRole 是全集群的，一旦绑错，影响面很大。下面三套配置里，只有确实需要跨命名空间读资源的场景才用 ClusterRole。
3.1 Service 管理场景：只读 SA 配置
假设你有一个监控组件，需要读取所有命名空间里的 Service 和 Endpoints，但不允许修改。这种跨命名空间的只读需求，适合用 ClusterRole 加 ClusterRoleBinding。
# service-reader.yaml apiVersion: v1 kind: ServiceAccount metadata: name: service-reader namespace: monitoring --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: service-reader-role rules: - apiGroups: [""] resources: ["services", "endpoints"] verbs: ["get", "list", "watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: service-reader-binding subjects: - kind: ServiceAccount name: service-reader namespace: monitoring roleRef: kind: ClusterRole name: service-reader-role apiGroup: rbac.authorization.k8s.io这里apiGroups: [""]表示核心 API 组，Service 和 Endpoints 都在这个组里。verbs只给了get/list/watch，没有create/update/delete，所以这个 SA 只能看不能改。如果你只想让它看某个命名空间，把 ClusterRole 换成 Role、ClusterRoleBinding 换成 RoleBinding，并加上namespace字段即可。
3.2 Ingress 管理场景：命名空间内可写
Ingress 通常由运维或者发布系统管理，需要创建和更新 Ingress 资源，但不需要动集群级别的其他东西。这种场景用 Role 加 RoleBinding 最合适。
# ingress-manager.yaml apiVersion: v1 kind: ServiceAccount metadata: name: ingress-manager namespace: production --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: ingress-manager-role namespace: production rules: - apiGroups: ["networking.k8s.io"] resources: ["ingresses"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] - apiGroups: [""] resources: ["services"] verbs: ["get", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: ingress-manager-binding namespace: production subjects: - kind: ServiceAccount name: ingress-manager namespace: production roleRef: kind: Role name: ingress-manager-role apiGroup: rbac.authorization.k8s.io注意 Ingress 的 apiGroup 是networking.k8s.io，不是核心组。很多新手写错这里，导致权限不生效。另外我额外给了 services 的只读权限，因为 Ingress 的 backend 需要引用 Service，发布系统有时会校验 Service 是否存在。
3.3 Dashboard 管理插件场景：区分管理员和只读用户
Dashboard 是最容易出权限事故的地方。我的建议是：永远不要给普通用户绑 cluster-admin。正确做法是建两个 SA，一个只读，一个受限管理。
先看只读用户的配置：
# dashboard-viewer.yaml apiVersion: v1 kind: ServiceAccount metadata: name: dashboard-viewer namespace: kubernetes-dashboard --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: dashboard-viewer-role rules: - apiGroups: [""] resources: ["pods", "services", "configmaps", "namespaces", "nodes"] verbs: ["get", "list", "watch"] - apiGroups: ["apps"] resources: ["deployments", "statefulsets", "daemonsets", "replicasets"] verbs: ["get", "list", "watch"] - apiGroups: ["networking.k8s.io"] resources: ["ingresses"] verbs: ["get", "list", "watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: dashboard-viewer-binding subjects: - kind: ServiceAccount name: dashboard-viewer namespace: kubernetes-dashboard roleRef: kind: ClusterRole name: dashboard-viewer-role apiGroup: rbac.authorization.k8s.io这个配置允许查看 Pod、Service、Deployment、Ingress 等常用资源，但不能创建、修改、删除。对于大多数开发和测试同学，这个权限已经够用了。
如果你确实需要一个管理员 SA，也不要直接用cluster-admin，而是自定义一个范围收敛的 ClusterRole。比如只允许管理指定命名空间的资源：
# dashboard-admin.yaml apiVersion: v1 kind: ServiceAccount metadata: name: dashboard-admin namespace: kubernetes-dashboard --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: dashboard-admin-role namespace: production rules: - apiGroups: ["", "apps", "networking.k8s.io"] resources: ["*"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: dashboard-admin-binding namespace: production subjects: - kind: ServiceAccount name: dashboard-admin namespace: kubernetes-dashboard roleRef: kind: Role name: dashboard-admin-role apiGroup: rbac.authorization.k8s.io这样这个 SA 只能在 production 命名空间里操作，动不了其他命名空间，也动不了集群级别的资源。Dashboard 登录时用这个 SA 的 Token，权限边界就清晰了。
获取 Token 的命令是：
kubectl -n kubernetes-dashboard create token dashboard-viewer注意 Token 默认有效期有限，生产环境建议配合 OAuth2 Proxy 或者 Dex 做统一登录，而不是长期用静态 Token。
4. 验证请求：用 kubectl auth can-i 确认权限边界
配置写完不代表生效，必须验证。kubectl auth can-i是最直接的验证工具，它模拟一个身份去问 API Server："我能不能做这件事"，返回 yes 或 no，不会真正执行操作。
基本语法是：
kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<namespace>:<sa-name>注意--as后面的格式是固定的：system:serviceaccount:命名空间:SA名字。这个格式写错，验证结果就没意义。
先验证 Service 只读 SA：
kubectl auth can-i list services \ --as=system:serviceaccount:monitoring:service-reader # 预期输出：yes kubectl auth can-i delete services \ --as=system:serviceaccount:monitoring:service-reader # 预期输出：no再验证 Ingress 管理 SA：
kubectl auth can-i create ingresses \ --as=system:serviceaccount:production:ingress-manager \ -n production # 预期输出：yes kubectl auth can-i create ingresses \ --as=system:serviceaccount:production:ingress-manager \ -n default # 预期输出：no，因为 Role 只绑在 production这里-n参数很关键。对于 Role 和 RoleBinding，权限只在绑定的命名空间内生效，所以验证时必须指定命名空间。如果不指定，默认是default，结果可能和你想的不一样。
验证 Dashboard 只读 SA：
kubectl auth can-i list pods \ --as=system:serviceaccount:kubernetes-dashboard:dashboard-viewer \ -n production # 预期输出：yes kubectl auth can-i delete pods \ --as=system:serviceaccount:kubernetes-dashboard:dashboard-viewer \ -n production # 预期输出：no除了单条验证，你还可以列出某个 SA 的全部权限：
kubectl auth can-i --list \ --as=system:serviceaccount:production:ingress-manager \ -n production这个命令会输出一个表格，列出该身份在指定命名空间内能做的所有操作。我建议每次配完 RBAC 都跑一遍，看看有没有意外的权限泄漏。比如你本来只想给 Ingress 权限，结果发现还能删 Pod，那说明绑定关系写错了。
还有一个实用技巧：验证 Pod 内部实际使用的身份。进入 Pod 后执行：
kubectl exec -it <pod-name> -- cat /var/run/secrets/kubernetes.io/serviceaccount/namespace这会显示当前 Pod 挂载的 SA 所在命名空间。再结合kubectl auth can-i就能确认 Pod 的真实权限。
如果验证结果和预期不符，先检查三件事：apiGroup 写对没有、verbs 是否包含目标动作、绑定关系的 namespace 是否匹配。这三个是最常见的出错点。
5. 本篇常见错排查：401、proxy failed、OAuth 报错怎么解
权限配置过程中，报错信息往往不够直白。这一节我把几个高频错误和排查思路整理出来，你遇到时可以对照。
错误一：Dashboard 登录报 401 Unauthorized
这个通常不是 RBAC 的问题，而是 Token 本身的问题。可能原因有几个：Token 过期了、Token 复制时带了换行或空格、或者 SA 根本不存在。
排查步骤：
# 确认 SA 存在 kubectl -n kubernetes-dashboard get sa dashboard-viewer # 重新生成 Token kubectl -n kubernetes-dashboard create token dashboard-viewer # 用 Token 直接调 API 验证 kubectl -n kubernetes-dashboard get secret如果 SA 存在但 Token 无效，检查是不是用了旧的 Secret 方式。K8s 1.24 之后 SA 不再自动创建长期 Token Secret，必须用create token动态生成。如果你还在找dashboard-viewer-token-xxxxx这种 Secret，那肯定找不到。
错误二：local proxy failed 或 connection refused
这个报错一般出现在用kubectl proxy访问 Dashboard 的时候。常见原因是 proxy 没启动、端口被占用、或者 Dashboard 的 Service 名字写错。
正确的访问路径是：
kubectl proxy # 然后访问 # http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/注意 URL 里的https:kubernetes-dashboard:是固定格式，冒号不能少。如果 Dashboard 装在别的命名空间，把kubernetes-dashboard换成实际命名空间。另外kubectl proxy默认只监听 localhost，如果你在远程服务器上跑，需要加--address=0.0.0.0，但这样会暴露到网络，生产环境千万别这么干，应该走 Ingress 加认证。
错误三：OAuth 登录后仍然提示无权限
如果你用 OAuth2 Proxy 或 Dex 做 Dashboard 登录，登录成功但看不到资源，说明 OAuth 身份和 K8s RBAC 没对上。OAuth 解决的是"你是谁"，RBAC 解决的是"你能干什么"，两者需要桥接。
常见做法是把 OAuth 返回的用户名或组名，通过 ClusterRoleBinding 绑到对应的 ClusterRole。比如：
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: oauth-viewer-binding subjects: - kind: Group name: "developers" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: dashboard-viewer-role apiGroup: rbac.authorization.k8s.io这里的Group名字要和 OAuth 返回的组名一致。如果对不上，登录后就是白板。
错误四：reading choices 相关报错
这个报错通常出现在用 Claude Code 或者类似编码工具接入模型服务时，工具尝试读取模型列表失败。排查方向是确认 Base URL 和 API Key 是否正确。如果你用的是 TaoToken，Base URL 应该是https://taotoken.net/api，Key 从控制台获取。可以在集群里起一个临时 Pod 测试连通性：
kubectl run curl-test --rm -it --image=curlimages/curl -- \ curl -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ https://taotoken.net/api/models如果返回模型列表，说明网络和 Key 都没问题；如果报 401，检查 Key；如果超时，检查集群的网络策略是否允许出站。
错误五：CC Switch 或 Cline MCP 配置后不生效
这类工具配置时，Base URL、API Key、Model ID 三件套必须齐全，缺一个都会失败。以 Cline 的 MCP 配置为例，settings 里要写清楚：
{ "mcpServers": { "taotoken": { "command": "npx", "args": ["-y", "@taotoken/mcp-server"], "env": { "TAOTOKEN_API_KEY": "你的Key", "TAOTOKEN_BASE_URL": "https://taotoken.net/api", "TAOTOKEN_MODEL": "claude-sonnet-4-20250514" } } } }Model ID 写错是最常见的问题，不同模型的 ID 不一样，去文档里确认。文档入口在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。
排查完这些，如果还有问题，用kubectl describe看事件，用kubectl logs看容器日志，大部分线索都在里面。
6. 把权限收口到日常流程里
配置写完、验证通过，只是开始。真正让权限策略发挥作用的，是把它变成日常流程的一部分。
我的做法是：每个新应用上线前，先确定它需要哪些资源、哪些动作，然后写一个专用的 ServiceAccount 和 Role，绝不复用 default。CI/CD 机器人单独一个 SA，只给创建 Job 和读取 PVC 的权限。监控组件单独一个 SA，只给只读权限。Dashboard 按角色分 SA，开发和运维看到的东西不一样。
定期审计也很重要。我一般每周跑一次：
kubectl get rolebindings,clusterrolebindings -A kubectl get clusterrolebinding -o json | jq '.items[] | select(.roleRef.name=="cluster-admin")'第二条命令会列出所有绑了 cluster-admin 的绑定关系。如果发现不该有的，及时清理。这个习惯能帮你挡住很多潜在风险。
如果你在集群里跑 AI Agent 或者模型调用服务，记得把模型 Key 放进 Secret，用专用 SA 挂载，Base URL 统一走 TaoToken 的 API 入口。这样权限和密钥两条线都收得住。需要管理多个 Key 的时候，控制台在 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite 。
最后留一个实操建议：把你验证权限的kubectl auth can-i命令写进 CI 流水线，每次 RBAC 变更后自动跑一遍。这样权限边界不会因为某次手滑而悄悄扩大。
