Kubernetes生产运维13RBAC报Forbidden别急着加cluster-admin怎么定位到底缺哪条权限写在前面RBAC报Forbidden时最省事也最危险的做法是直接给这个用户或ServiceAccount绑一个cluster-admin问题解决了。这样做的代价是权限失控一个本来只需要读某个命名空间Pod的服务拿到了整个集群的最高权限。一旦它被攻破或出bug影响面就是整个集群。正确的做法是定位到底缺哪一条权限然后只补这一条。这篇讲清楚RBAC的授权链Subject、Role、Binding、ServiceAccount怎么串起来Role和ClusterRole、RoleBinding和ClusterRoleBinding的区别和作用域用can-i精确定位缺失的权限最小权限的设计原则本文按照Kubernetes官方机制整理。由于当前没有连接可验证的实验集群命令和输出均为C级生产化重建不是生产原始记录。RBAC是安全相关配置任何授权变更都应遵循最小权限并留审计扩大权限前评估影响。一、先理解RBAC的授权链1.1 四个角色串成一条链RBAC授权由几个对象组合而成Subject谁 → 通过Binding绑定 → 关联到Role或ClusterRole能做什么 → Role里定义对哪些资源的哪些动作verbsSubject被授权的身份可以是User、Group或ServiceAccountRole/ClusterRole一组权限规则定义对哪些资源resources能做哪些动作verbs如get、list、create、deleteRoleBinding/ClusterRoleBinding把Subject和Role绑起来权限才生效只有Role没有Binding权限不生效只有Binding没有匹配的Subject也不生效。1.2 应用内的身份是ServiceAccountPod里运行的应用访问API Server时用的身份是ServiceAccount。每个命名空间有个默认ServiceAccount也可以为工作负载指定专用的。所以当一个应用报Forbidden通常要查的是它用的ServiceAccount有没有被绑定到包含所需权限的Role。1.3 Forbidden是授权结论不是资源不存在一个重要判断Forbidden表示当前身份没有权限执行这个动作不代表目标资源不存在也不代表资源本身有问题。这点第02篇也提过。看到Forbidden方向是查权限不是查资源。二、Role和ClusterRole的区别2.1 作用域不同对象作用域Role命名空间级只在所在命名空间内有效ClusterRole集群级可用于集群范围资源或被复用到各命名空间RoleBinding在某个命名空间内授权ClusterRoleBinding集群范围授权2.2 组合方式和作用域关键的组合规则RoleBinding Role在该命名空间内授予Role的权限RoleBinding ClusterRole把ClusterRole的权限限定在该RoleBinding所在的命名空间生效。这是复用ClusterRole又不给全集群权限的常用方式ClusterRoleBinding ClusterRole全集群范围授予权限影响面最大要谨慎一个常见误解以为绑了ClusterRole就是全集群权限。其实如果用的是RoleBinding权限被限定在那个命名空间。作用域由Binding的类型决定。2.3 集群范围资源只能用ClusterRole像Node、PersistentVolume、Namespace这类不属于任何命名空间的资源只能通过ClusterRole加ClusterRoleBinding授权RoleBinding管不了。三、用can-i精确定位缺失权限kubectl auth can-i是权限排查的核心工具它直接回答某个身份能不能做某件事。3.1 查自己能不能kubectl auth can-i get pods-nnamespacekubectl auth can-i create deployments-nnamespace返回yes或no直接告诉你有没有这条权限。3.2 查某个ServiceAccount能不能关键排查应用权限时用--as模拟那个ServiceAccountkubectl auth can-i list configmaps\-nnamespace\--assystem:serviceaccount:namespace:serviceaccount这条命令直接回答这个ServiceAccount能不能list这个命名空间的configmaps是定位应用Forbidden的最快方法。3.3 列出一个身份的所有权限kubectl auth can-i--list\-nnamespace\--assystem:serviceaccount:namespace:serviceaccount这会列出该身份在该命名空间能做的所有动作一眼看出缺了什么。3.4 从错误信息读关键字段Forbidden错误通常包含关键信息Error from server (Forbidden): configmaps is forbidden: User system:serviceaccount:app:reader cannot list resource configmaps in API group in the namespace app从中能直接读出身份system:serviceaccount:app:reader缺的动作list资源configmapsAPI组核心组空命名空间app有了这四项就知道要补什么权限而不是盲目加cluster-admin。四、RBAC排查决策树报Forbidden │ ├─ 从错误信息读出身份、动作、资源、API组、命名空间 │ ├─ 用can-i --as确认这个身份到底缺哪条 │ └─ can-i --list看它现有全部权限 │ ├─ 查授权链哪一环断了 │ ├─ 有没有对应的Role/ClusterRole定义了这条权限 │ ├─ 有没有RoleBinding/ClusterRoleBinding把身份和Role绑上 │ ├─ 绑定的Subject是否正好是这个身份名字、命名空间、类型 │ └─ 作用域对不对RoleBinding只在本命名空间 │ ├─ 只补缺失的最小权限不加cluster-admin │ └─ 补权限审计与治理先看现有的Role和Bindingkubectl get role,rolebinding-nnamespacekubectl get clusterrole,clusterrolebinding|grep关键字kubectl describe rolebindingbinding-name-nnamespacedescribe能看到Binding绑的是哪个Role、哪些Subject。五、C级生产化重建案例应用升级后读不到ConfigMap5.1 先说明哪些是真的哪些是重建的下面不是作者声称亲历的生产事故而是根据Kubernetes RBAC机制构造的生产化重建。内容证据属性Subject、Role、Binding、ServiceAccount和can-i的机制Kubernetes官方机制应用新增读ConfigMap功能后报Forbidden机制一致的重建场景Namespace、资源名、身份和终端输出为讲解构造的说明性信息ServiceAccount的Role缺少configmaps的list权限模拟根因不是作者生产记录只补一条权限后验证恢复受控验证设计不声称已在当前集群执行所有输出按真实对象关系编排但没有连接实际集群采集读者不能把下面的名称或输出引用为真实事故数据。5.2 现场卡片一个应用升级后新增了读取ConfigMap做动态配置的功能上线后日志报Forbidden功能不可用。团队最初想直接给它的ServiceAccount加cluster-admin让它先跑起来。重建的相对时间线相对时间观察或动作当时能够得出的结论T00应用日志报configmaps forbidden存在权限问题原因未知T02有人提议加cluster-admin高风险先不做T04从错误信息读出缺list configmaps定位到具体动作和资源T06can-i确认ServiceAccount确实不能list configmaps主假设成立T验证只补list configmaps权限后验证单变量验证相对时间只表示排查顺序不代表真实数值。5.3 从错误信息读关键字段应用日志里的错误configmaps is forbidden: User system:serviceaccount:app:config-reader cannot list resource configmaps in API group in the namespace app读出四要素身份ServiceAccountconfig-reader命名空间app动作list资源configmaps命名空间app方向明确是权限不是ConfigMap不存在。5.4 用can-i确认NSappSAconfig-reader kubectl auth can-i list configmaps-n$NS\--assystem:serviceaccount:$NS:$SA机制一致的说明性输出no确认这个ServiceAccount确实不能list configmaps。再看它现有权限kubectl auth can-i--list-n$NS\--assystem:serviceaccount:$NS:$SA机制一致的说明性输出Resources Non-Resource URLs Resource Names Verbs pods [] [] [get list watch] pods/log [] [] [get]它只有读Pod的权限没有configmaps。升级新增的读ConfigMap功能超出了原有授权。5.5 查授权链kubectl get rolebinding-n$NS-owide kubectl describe role config-reader-role-n$NS机制一致的说明性输出RoleBinding把config-reader绑到config-reader-role Role config-reader-role rules: Resources Verbs pods [get list watch] pods/log [get]Role里只有pods相关权限没有configmaps。授权链是通的Binding存在、Subject正确只是Role缺了这条规则。证据链错误明确是list configmaps被拒 can-i确认该SA不能list configmaps can-i --list显示它只有pods权限 Role定义里没有configmaps规则 升级新增了读ConfigMap功能 强烈支持Role缺少configmaps的list权限这仍是主假设验证前不写成根因已闭环。5.6 止损与单变量验证绝不加cluster-admin。单变量修正只给Role补上configmaps的读权限不动其他apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:name:config-reader-rolenamespace:apprules:-apiGroups:[]resources:[pods,pods/log]verbs:[get,list,watch]-apiGroups:[]# 新增这一条最小权限resources:[configmaps]verbs:[get,list,watch]验证kubectl apply-fconfig-reader-role.yaml kubectl auth can-i list configmaps-n$NS\--assystem:serviceaccount:$NS:$SA机制一致的说明性输出yes补上这一条后can-i返回yes应用功能恢复。只给了它需要的configmaps读权限没有扩大到其他资源更没有给集群级权限。这些输出分别证明不同范围的事实输出能够支持不能单独证明can-i返回yes缺失权限已补上应用其他动作都够只加了configmaps规则遵循了最小权限未来功能不再需要新权限应用功能恢复该功能所需授权到位所有链路都正常5.7 根因闭环条件修正只有给Role补configmaps读权限这一项主要变量。补后can-i从no变yes功能恢复。授权链其他环节Binding、Subject本来就对只是Role缺规则。没有使用cluster-admin或扩大到无关资源。应用只拿到它需要的权限符合最小权限。如果补了还报Forbidden就检查是不是API组或资源名写错、命名空间不对、或者有多个同名Role/Binding混淆。六、最小权限的设计和治理层次动作关键边界精确定位从错误读四要素用can-i确认Forbidden是授权结论不是资源不存在最小授权只补缺失的资源和动作绝不用cluster-admin图省事作用域控制优先RoleBinding限定命名空间慎用ClusterRoleBinding集群级授权影响面最大专用身份为工作负载用专用ServiceAccount不共用默认便于隔离和审计审计定期审查谁有什么权限回收多余授权权限只增不减会失控治理RBAC变更走评审纳入版本管理权限变更可追溯一个核心原则权限应该按需最小授予而不是先给大权限再想着收。收权限比给权限难得多因为怕影响业务。所以一开始就最小化。七、权限排查清单定位 [ ] 从Forbidden错误读出身份、动作、资源、API组、命名空间 [ ] 用can-i --as确认该身份缺哪条 [ ] 用can-i --list看它现有全部权限 查授权链 [ ] 有没有Role/ClusterRole定义了这条权限 [ ] 有没有Binding把身份和Role绑上 [ ] 绑定的Subject名字、命名空间、类型是否完全匹配 [ ] 作用域对不对RoleBinding只在本命名空间集群资源要ClusterRole 修复 [ ] 只补缺失的最小权限 [ ] 没有使用cluster-admin [ ] 用专用ServiceAccount而非默认 [ ] 变更纳入版本管理和审计八、监控与治理8.1 监控与审计什么谁绑定了cluster-admin或高权限ClusterRoleServiceAccount的权限范围授权变更记录审计日志Forbidden错误的频率和来源长期未使用的高权限身份8.2 治理原则按需最小授权一开始就不给多余权限工作负载用专用ServiceAccount不共用默认SA优先用RoleBinding限定命名空间ClusterRoleBinding严格评审RBAC配置纳入版本管理变更走评审定期审查和回收多余权限尤其是cluster-admin九、常见误区误区1报Forbidden就加cluster-admin权限失控一旦被攻破影响整个集群应只补缺失的最小权限。误区2把Forbidden当成资源不存在Forbidden是授权结论方向是查权限不是查资源。误区3以为绑ClusterRole就是全集群权限RoleBinding引用ClusterRole时权限被限定在该命名空间。误区4集群资源用RoleBinding授权Node、PV等集群资源只能用ClusterRole加ClusterRoleBinding。误区5所有应用共用默认ServiceAccount不利于隔离和审计应为工作负载用专用SA。误区6只加权限不回收权限只增不减会逐渐失控要定期审查。误区7不用can-i靠猜can-i能精确回答某身份能不能做某事比猜快得多。误区8忽略Subject的精确匹配Subject的名字、命名空间、类型任一不符绑定都不生效。十、面试怎么说60秒版本RBAC报Forbidden我绝不直接加cluster-admin。先从错误信息读出身份、动作、资源、API组和命名空间这几要素Forbidden是授权结论不是资源不存在。然后用kubectl auth can-i加–as模拟那个ServiceAccount精确确认缺哪条can-i --list看它现有全部权限。再查授权链有没有Role定义这条权限、有没有Binding绑上、Subject是否完全匹配、作用域对不对。最后只补缺失的最小权限用RoleBinding限定命名空间绝不扩大。RBAC是安全配置权限按需最小授予一开始就别给多。3分钟场景版本假设应用升级后报configmaps forbidden。我先从错误读出是ServiceAccount config-reader不能list configmaps方向是权限不是ConfigMap本身。用can-i --as模拟这个SA确认返回no再用can-i --list看到它只有pods权限没有configmaps因为升级新增的读配置功能超出了原授权。查Role发现只定义了pods规则。根因是Role缺configmaps的list权限。我不会加cluster-admin而是只给Role补一条configmaps的get/list/watchapply后can-i返回yes功能恢复。这样应用只拿到它需要的权限符合最小权限原则。这体现了RBAC排查的核心精确定位到缺哪一条只补那一条而不是用大权限掩盖。十一、延伸问答1. Forbidden一定是权限问题吗是。Forbidden表示当前身份没权限执行该动作不代表资源不存在。2. can-i怎么查ServiceAccount用--assystem:serviceaccount:命名空间:名字模拟该身份。3. Role和ClusterRole区别Role命名空间级ClusterRole集群级或可复用到各命名空间集群资源只能用ClusterRole。4. 绑了ClusterRole就是全集群权限吗不一定。RoleBinding引用ClusterRole时权限限定在该命名空间作用域由Binding类型决定。5. 为什么不能随便加cluster-admin权限失控被攻破或出bug影响整个集群应只补最小权限。6. 应用用什么身份访问APIServiceAccount建议为工作负载用专用SA而非默认。7. 补了权限还报Forbidden怎么办检查API组、资源名、命名空间是否写对Subject是否精确匹配有无同名对象混淆。8. RBAC怎么治理按需最小授权、专用SA、优先RoleBinding、纳入版本管理、定期审查回收。小结RBAC授权链是Subject通过Binding关联Role缺任一环权限都不生效。Forbidden是授权结论不是资源不存在。Role命名空间级ClusterRole集群级作用域由Binding类型决定。RoleBinding引用ClusterRole时权限限定在本命名空间。用can-i加–as精确定位某身份缺哪条权限。只补缺失的最小权限绝不加cluster-admin。工作负载用专用ServiceAccount便于隔离和审计。权限按需最小授予定期审查回收纳入版本管理。下一篇预告下一篇进入Kubernetes集群无中断升级。我们会讲清API兼容检查、控制面和节点升级顺序、PDB和节点驱逐、验证与回退并整理一份升级Runbook。参考资料Kubernetes官方文档Using RBAC AuthorizationKubernetes官方文档AuthorizationKubernetes官方文档Service AccountsKubernetes官方文档Configure Service Accounts for PodsKubernetes官方文档AuthenticatingKubernetes官方文档RBAC Good PracticesKubernetes官方文档Controlling Access to the Kubernetes APIKubernetes官方文档kubectl auth can-iKubernetes官方文档Managing Service AccountsKubernetes官方文档Security Checklist