CKA倒计时第24天今天把RBAC里最容易混淆的一组概念彻底理清ClusterRole和ClusterRoleBinding。为什么单独拿一天来写这对组合因为CKA考试里权限相关题目几乎必考而且大概率不是单纯考Role而是考集群级授权。我考前刷题时发现很多人对Role和ClusterRole的区别靠死记硬背一上考场遇到创建ClusterRole给某用户管理PV这类题就开始犯迷糊。这篇笔记不想做成官方文档的翻译版而是从备考应试和真实运维两个角度把ClusterRole和ClusterRoleBinding讲透顺带把我在模拟环境里踩过的坑也一并写了希望能帮你省下考场上宝贵的排错时间。1. 先搞懂一件事为什么有了RoleK8s还要设计ClusterRole很多初学者学RBAC时第一个问题就是Role用得好好的为什么还要搞一个ClusterRole这不是K8s设计者闲得慌而是Namespace级别的Role天然管不了集群本身的事。1.1 Role的作用域局限一句话理解Namespace级授权一句话概括Role管的是某个Namespace内部的资源权限ClusterRole管的是整个集群范围的资源权限。这里有三个容易被忽略的细节Role只能授权给Namespace内的资源比如Pod、Service、Deployment这类有Namespace归属的资源集群级资源Node、PV、StorageClass、Namespace本身Role根本碰不到Role连跨Namespace查看Pod这种事都做不到因为它的规则天然被限定在绑定时的那个Namespace里。打个比方Role就像一张办公楼的门禁卡只能刷开你所在那一层的大多数房间但电梯间、配电房、整栋楼的监控室你都没权限。ClusterRole则更像物业总控卡可以定义整栋楼任何一个房间你都有权进入或只有某些楼层你能进这类更灵活的规则。1.2 ClusterRole能管的三类资源ClusterRole的授权范围比Role大得多具体来说能覆盖三类对象集群级资源Node、PersistentVolume、StorageClass、VolumeAttachment、CSIDriver、ClusterRole本身、ClusterRoleBinding本身等跨Namespace资源比如所有Namespace下的Pod所有Namespace下的Service。只要你在rules里写了pods配合ClusterRoleBinding或跨Namespace的RoleBinding就能对全部Namespaces生效非资源型URL比如/healthz、/version这类HTTP路径这种授权没法用Role实现只有ClusterRole支持。这里有个关键理解不是说用了ClusterRole就一定能管所有东西而是ClusterRole的作用域是整个集群具体能管哪些资源取决于rules里写了什么。理解了这个就不会把集群级授权错误理解为全部权限。1.3 Role和ClusterRole的四种组合关系在CKA考试和真实运维里Role、ClusterRole、RoleBinding、ClusterRoleBinding四种对象存在四种组合。很多题目的坑就藏在组合方式里角色类型绑定类型效果典型场景RoleRoleBinding在同一Namespace内生效给某应用授予单Namespace内Pod读写权限RoleClusterRoleBinding语法合法但无实际意义建议避免无现实中基本不用ClusterRoleRoleBinding在指定Namespace内共享集群级角色定义把定义好的查看全集群Pod能力只授权给某个Namespace下的用户ClusterRoleClusterRoleBinding在整个集群范围生效给运维组授予管理所有Node的权限注意第二种组合Role绑定到ClusterRoleBinding语法上K8s会允许但Role本身的rules只匹配单个Namespace而ClusterRoleBinding绑定的是集群范围。官方明确不推荐这种用法考试时如果题目要求合理基本不会让你这么干。遇到模糊表述时优先选ClusterRole RoleBinding或ClusterRole ClusterRoleBinding。2. 把ClusterRole配置讲透从资源规则到聚合权限理解概念之后实操才是硬功夫。CKA考试中大量题目要求你直接写YAML或使用kubectl命令创建ClusterRole这一节把配置细节掰开揉碎。2.1 rules字段的完整语法拆解ClusterRole的核心是rules数组每个rule由三部分组成apiGroups、resources、verbs。以管理Node权限为例一个最小可用的ClusterRole长这样apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: node-admin rules: - apiGroups: [] resources: [nodes] verbs: [get, list, watch, create, update, patch, delete]其中apiGroups是最容易出错的地方。代表核心组也就是v1版本的那些资源比如pods、services、nodes、configmaps、secrets、endpoints、persistentvolumes等。如果你要操作apps组下的deployments就得写[apps]要用batch组下的cronjobs就得写[batch]。怎么记住推荐一条命令kubectl api-resources。它会列出每个资源对应的APIVersion和所属组考试时不确定就敲一下比死记硬背可靠得多。verbs则是动词集合常见的有get、list、watch、create、update、patch、delete还有一个冷门的deletecollection批量删除。注意get、list、watch三者是分开的get是读取单个对象list是读取集合watch是监听变化。只给get不给list某些命令比如kubectl get pods不带名字照样无权执行。2.2 一行命令生成ClusterRolekubectl create的应试技巧CKA考试中用kubectl一行命令比手写YAML快得多也少犯错。语法如下kubectl create clusterrole node-admin --verbget,list,watch,delete --resourcenodes如果要限定resourceName可以加--resource-name参数kubectl create clusterrole node-reader --verbget,list,watch --resourcenodes --resource-namenode01考试时题目没说必须写YAML用命令创建通常更快。命令创建的ClusterRole和YAML创建的完全等价描述出来也一样。不过要注意kubectl create clusterrole不支持一次创建包含多条rule的角色如果题目要求一个ClusterRole里同时包含pods和deployments的权限我更建议直接写YAML再apply或者分成两个命令分别创建再合并。实际上多rule场景手写YAML更稳。2.3 aggregationRule高级用法中的自动角色聚合大多数教程不讲aggregationRule但理解了它对RBAC整体认知会上升一个档次。简单说aggregationRule允许你把多个ClusterRole的rules动态合并成一个ClusterRole用于权限的模块化组合apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: combined-admin aggregationRule: clusterRoleSelectors: - matchLabels: rbac.example.com/aggregate: true rules: []然后其他ClusterRole只要带上rbac.example.com/aggregate: true这个label它的rules就会被自动合并到combined-admin里。这个机制在真实集群中常用于平台团队统一管理权限模板CKA考试基本不考但遇到聚合权限关键词时不要一脸懵就好。2.4 常用场景实例只允许查看Pod日志拿一个考试高频需求举例授予用户只读Pod和Pod日志权限。规则如下rules: - apiGroups: [] resources: [pods, pods/log] verbs: [get, list]注意pods/log和pods是分开的条目。很多考生初次写会漏掉pods/log结果用户看得到Pod状态却拉不了日志。这属于典型的资源子资源问题pods/status、pods/log、pods/exec都是pods的子资源必须单独列在resources里。3. ClusterRoleBinding的绑定逻辑Subject到底是什么ClusterRole定义的是能干什么Binding定义的是谁能这么干。ClusterRoleBinding把一组用户、组或ServiceAccount和ClusterRole绑定到一起权限立即在整个集群生效。3.1 Subject的三种类型User、Group、ServiceAccountClusterRoleBinding的subjects数组支持三种类型User代表最终用户比如alice通常在认证阶段就已确定。CKA考试环境一般没有配置外部身份提供商所以靠kubeconfig里的普通用户来区分并不常见Group代表一组用户比如system:masters、devops。给组授权后组内所有用户都继承权限ServiceAccount代表Pod或任务使用的身份这是K8s中最常用的一种因为ServiceAccount可以直接被Pod引用。三种类型的写法差异不大看一个综合示例apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: crb-node-admin roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: node-admin subjects: - kind: User name: alice apiGroup: rbac.authorization.k8s.io - kind: Group name: devops apiGroup: rbac.authorization.k8s.io - kind: ServiceAccount name: cka-sa namespace: kube-system注意这里的坑ServiceAccount必须指定namespace而User和Group则不需要namespace字段。roleRef里的apiGroup固定是rbac.authorization.k8s.io。3.2 为什么考试中更常用ServiceAccountCKA模拟题里经常要求创建一个ServiceAccount并授予某个ClusterRole权限。原因很简单考试环境里没有真实的用户系统题目通常通过ServiceAccount来模拟身份。而且ServiceAccount可以直接通过kubectl create token获取一个token来测试调用K8s API也能挂载到Pod中让Pod获得权限实操性很强。所以我的建议是无论题目里写的是用户还是ServiceAccount只要没有给出明确的OIDC等外部身份配置考试中就直接创建ServiceAccount作为一个Subject来绑定然后用kubectl auth whoami之类的命令验证。但注意读题——如果题目明确写着创建User alice那你要按题目要求来CKA考点的Exam环境里也可能会用kubectl config set-credentials来创建用户。3.3 一条命令创建ClusterRoleBinding创建ClusterRoleBinding最直接的方式kubectl create clusterrolebinding cka-bind --clusterrolenode-admin --serviceaccountkube-system:cka-sa参数说明--clusterrole指定要绑定的ClusterRole名称--serviceaccountnamespace:name指定ServiceAccount这是考试中最常用的方式如果绑定用户用--useralice绑定组用--groupdevops。也可以用YAML形式apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: cka-bind roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: node-admin subjects: - kind: ServiceAccount name: cka-sa namespace: kube-system创建后检查是否生效kubectl get clusterrolebinding cka-bind -o yaml3.4 多条规则的叠加逻辑是与有些人以为多条rule之间是或的关系错了。rules数组里的多个条目取的是并集但每条rule内部apiGroups、resources、verbs三者之间是与的关系。也就是说要成功执行一个操作必须同时满足该条目中的apiGroups、resources、verbs三项匹配。一个rule没写到的API组或资源默认是拒绝的。举例来说如果你写了一条rule只管pods的get权限另一条rule只管nodes的get权限那么拥有者可以读pods也可以读nodes但依然不能创建Pod也不能删除Node。每条规则之间是或的逻辑叠加规则内部是与的逻辑约束。这个点考试虽然不直接考概念但在写多rule角色时理解它才能保证规则完整不冗余。3.5 验证权限的利器kubectl auth can-i验证权限最实用的命令就是kubectl auth can-i没有之一。用法kubectl auth can-i get pods --assystem:serviceaccount:kube-system:cka-sa kubectl auth can-i delete nodes --assystem:serviceaccount:kube-system:cka-sa--as参数可以模拟某个身份无需真的切换kubeconfig。如果返回yes说明有权限no则没有。还有两个变体很实用# 查看某个身份所有权限 kubectl auth can-i --list --assystem:serviceaccount:kube-system:cka-sa # 带namespace限定测试跨命名空间权限 kubectl auth can-i get pods -n default --assystem:serviceaccount:kube-system:cka-sa考试时创建完权限后立刻用can-i验证一下既确认配置正确也能在题目要求的验证环节拿到实锤。这个习惯我强烈建议养成省得交卷后心里没底。4. CKA高频考点ClusterRole配合RoleBinding实现跨Namespace授权如果说ClusterRoleClusterRoleBinding是RBAC的全面授权组合那ClusterRoleRoleBinding就是精准授权组合。CKA考试里这个组合出现的频率极高因为题目常常设置这样的场景集群里已经存在一个集群级角色但你只想让它在某个Namespace内生效。4.1 为什么说ClusterRoleRoleBinding最实用举个例子平台团队定义了一个名为deployment-manager的ClusterRole包含对deployments的完全操作权限。现在研发A组只需要在namespace-a里使用这个权限研发B组只需要在namespace-b里使用。如果直接把ClusterRole用ClusterRoleBinding绑定给A组那么A组在整个集群所有Namespace都能管理Deployment风险太大。正确做法是把这个ClusterRole用RoleBinding绑定到namespace-a这样A组只有在namespace-a内才有deployment-admin权限。ClusterRole相当于定义了通用权限模板RoleBinding决定这个模板在哪个Namespace落地。这个设计极大提升了权限配置的复用性同一个ClusterRole配合不同RoleBinding可以为不同租户提供同等权限但互不越界。4.2 真题风格模拟给指定账号某Namespace下的Pod管理权我们完整演练一道CKA风格题。题目大意在default命名空间创建一个ServiceAccountpod-admin-sa并确保它能在default命名空间中管理Pod所有操作权限但不允许查看其他NameSpace的Pod。操作步骤创建ClusterRole为什么用ClusterRole因为题目可以接受你在集群内定义角色再用RoleBinding限定Namespace范围如果你懒得想直接创建一个Namespace级别Role也可以但这里我想演示跨Namespace授权场景kubectl create clusterrole pod-manager --verbcreate,delete,get,list,watch,update,patch --resourcepods创建ServiceAccountkubectl create sa pod-admin-sa -n default创建RoleBinding将ClusterRole绑定到default这个Namespacekubectl create rolebinding pod-admin-binding --clusterrolepod-manager --serviceaccountdefault:pod-admin-sa -n default注意rolebinding和clusterrolebinding的区别这里用的是rolebinding作用域被限定在default。验证kubectl auth can-i delete pods -n default --assystem:serviceaccount:default:pod-admin-sa kubectl auth can-i delete pods -n kube-system --assystem:serviceaccount:default:pod-admin-sa第一个返回yes第二个返回no。如果输出都是no多半是RoleBinding没创建到正确的Namespace或者serviceaccount语法写错了。我见过很多人把--serviceaccountdefault:pod-admin-sa写成--userpod-admin-sa权限自然不生效。4.3 用kubectl auth whoami验证当前身份考试时如果环境里配置了多个用户或ServiceAccount使用kubectl auth whoami可以快速确认当前正在使用的身份。这在排查为什么权限生效不了时非常关键。比如你用--as模拟身份后发现权限异常先whoami确认模拟是否生效再去看配置能省下大量时间。4.4 这类题目里最容易漏掉的参数--clusterrole创建RoleBinding时如果漏加--clusterrole默认会绑一个名为default的Role而不是你期望的ClusterRole。正确的完整写法kubectl create rolebinding test-rb --clusterrolepod-manager --serviceaccountdefault:pod-admin-sa -n default kubectl create rolebinding test-rb --rolepod-manager --serviceaccountdefault:pod-admin-sa -n default这两行有意义的不同前者绑定的是一个集群级的ClusterRole后者绑定的是一个Namespace级的Role。如果你用kubectl create rolebinding --rolexxx而这个名字并不存在命令会直接报错。而如果使用--clusterrolexxx但xxx不存在也会报错。考点就是你能不能区分什么时候用role什么时候用clusterrole。5. 权限不生效我在模拟环境里踩过的三个坑有时候配置看起来完全正确但kubectl auth can-i返回no或者调用API时返回403。我在练习中反复踩过几个坑按出现频率排列如下5.1 坑一resources子资源没带全最常见的是只写了resources: [pods]忘了具体子资源。比如要授予exec权限就得写resources: [pods/exec]logs、status、portforward、proxy等都是类似情况。想一次性覆盖Pod所有子资源可以写resources: [pods, pods/log, pods/exec, pods/status, pods/portforward]但不要图省事写成[pods/*]K8s CPU和内存很慷慨规则匹配器却比较耿直不支持通配子资源。另外要注意目前K8s的resources字段可以用*来表示该apiGroups下所有资源但通配符只支持到资源名层面比如resources: [*]是合法的代表所有资源。可pods/*这种写法不行。5.2 坑二apiGroups写成空字符串还是core很多新手写YAML时把核心组写成apiGroups: [core]或apiGroups: [v1]这两种写法都是错的。核心组的正确写法是空字符串apiGroups: []如果要表达所有API组用通配符apiGroups: [*]为了让你更有体感我列了一张高频资源所属组的速查表常见资源所属API组说明pods, services, nodes, configmaps, secrets核心组注意是空字符串deployments, statefulsets, replicasets, daemonsetsapps常用工作负载组jobs, cronjobsbatch批处理任务ingresses, networkpoliciesnetworking.k8s.io网络资源persistentvolumes, storageclasses, csinodesstorage.k8s.io存储相关eventsevents.k8s.io事件API同时也在核心组考试时不确定就敲kubectl api-resources -o wide查看API Group列快且准。5.3 坑三用名字相同的ClusterRole和Role覆盖了权限K8s RBAC本质是默认拒绝、显式允许。但更隐蔽的问题是如果同时存在一个ClusterRole和一个Role同名且不同绑定关系指向同一个用户可能会出现你期望的权限被看起来没生效的情况。比如你已经通过ClusterRoleBinding给了用户user1查看Secret的权限又在user1所在的Namespace创建了一个RoleBinding绑定了一个没有Secret权限的Role。因为两条授权路径都有效只要其中一条允许就能成功访问。所以当can-i返回no时先检查是不是完全没有授权路径而不是怀疑权限叠加冲突。这里分享一个我的排错顺序先用kubectl auth can-i verb resource --asidentity确认问题如果返回no用kubectl describe clusterrolebinding name和kubectl describe rolebinding name查看绑定的Subject是否包含该身份用kubectl get clusterrole name -o yaml查看rules是否覆盖目标资源和动词检查apiGroups是否匹配尤其是核心组的空字符串检查资源是否写的是子资源如pods/log而非pods。5.4 权限陷阱的额外例子wildcard的迷惑性resources字段支持*通配符比如resources: [*]。意思是对该apiGroups下所有资源生效含子资源。很多参考文档说对Pod所有子资源很方便但注意如果你写成apiGroups: [], resources: [*]确实包含了pods、pods/log等一切核心组资源。但如果你只想授权核心组下所有资源这种做法看着灵活实际容易给予过宽权限考题如果问最小权限方案还是要精确到资源名。6. 冲刺阶段怎么练ClusterRole相关题我的考前练习法与上考场建议最后这部分写给正在冲刺CKA、时间紧任务重的朋友。ClusterRole相关的题目本质上考你对角色-绑定-作用域-主体四个概念的快速组合能力考前练熟就稳了。6.1 每天5分钟命令记忆法不要每天背一堆YAML模板我更推荐用命令式记忆法每天花5分钟反复敲这几条命令直到形成肌肉记忆kubectl create clusterrole name --verbverbs --resourceresources kubectl create clusterrolebinding name --clusterrolerole --useruser kubectl create clusterrolebinding name --clusterrolerole --serviceaccountns:sa kubectl create rolebinding name --clusterrolerole --serviceaccountns:sa -n ns kubectl auth can-i verb resource --asidentity尤其要练会--resource-name限定单个资源对象这是CKA考试反复出现的考点。比如只允许查看node01这种操作命令是kubectl create clusterrole node-reader --verbget,list,watch --resourcenodes --resource-namenode016.2 考前模拟题清单以下10个场景是我自己考前练过的每个都值得敲一遍给指定用户授予全集群Pod只读权限给指定ServiceAccount授予集群内创建/删除Deployment权限限定某用户在单个Namespace内管理ConfigMap限定某Viewer仅能查看Pod及日志授予用户管理Node但不允许删除特定的master节点创建一个ClusterRole允许对PV做所有操作并用ClusterRoleBinding绑定到组通过RoleBinding复用集群级角色仅在某一个Namespace生效测试kubectl auth can-i --list输出确认权限列表干净、无意外多授权给ServiceAccount授予读取Secret权限然后通过kubectl create token获取token用curl访问API验证删除错误的ClusterRoleBinding后确认权限立刻失效再重新绑定。6.3 考场上的操作节奏与时间分配CKA考试题目通常不超过17道时间约2小时。RBAC题一般能在3-5分钟内完成属于性价比较高的题如果你花超过10分钟还在折腾一条权限先跳下一题最后再回来。另外强烈建议每道题提交前做一次can-i验证因为RBAC题目的结果非黑即白验证通过就是满分验证不通过就是零分值得花这十几秒。6.4 后续还能怎么扩展通过今天的梳理我已经把CKA RBAC的大半考点都覆盖了。后面如果再碰到更复杂的题目比如与ServiceAccount的imagePullSecrets结合、与AdmissionConfiguration的权限策略结合你都能顺着角色-绑定-主体-作用域这套框架去拆解。权限设计本质上就是一个逻辑题只要思路清晰配置就不会歪。极限冲刺阶段把这些基础组合题练成本能反应比临考前还在翻文档要高效得多。我个人在备考第24天这个节点已经开始把所有RBAC题型从头各练三遍练完之后碰到再绕的授权题也不慌了。