Kubernetes生產(chǎn)運(yùn)維13RBAC報(bào)Forbidden別急著加cluster-admin怎么定位到底缺哪條權(quán)限寫在前面RBAC報(bào)Forbidden時(shí)最省事也最危險(xiǎn)的做法是直接給這個(gè)用戶或ServiceAccount綁一個(gè)cluster-admin問題解決了。這樣做的代價(jià)是權(quán)限失控一個(gè)本來只需要讀某個(gè)命名空間Pod的服務(wù)拿到了整個(gè)集群的最高權(quán)限。一旦它被攻破或出bug影響面就是整個(gè)集群。正確的做法是定位到底缺哪一條權(quán)限然后只補(bǔ)這一條。這篇講清楚RBAC的授權(quán)鏈Subject、Role、Binding、ServiceAccount怎么串起來Role和ClusterRole、RoleBinding和ClusterRoleBinding的區(qū)別和作用域用can-i精確定位缺失的權(quán)限最小權(quán)限的設(shè)計(jì)原則本文按照Kubernetes官方機(jī)制整理。由于當(dāng)前沒有連接可驗(yàn)證的實(shí)驗(yàn)集群命令和輸出均為C級生產(chǎn)化重建不是生產(chǎn)原始記錄。RBAC是安全相關(guān)配置任何授權(quán)變更都應(yīng)遵循最小權(quán)限并留審計(jì)擴(kuò)大權(quán)限前評估影響。一、先理解RBAC的授權(quán)鏈1.1 四個(gè)角色串成一條鏈RBAC授權(quán)由幾個(gè)對象組合而成Subject誰 → 通過Binding綁定 → 關(guān)聯(lián)到Role或ClusterRole能做什么 → Role里定義對哪些資源的哪些動(dòng)作verbsSubject被授權(quán)的身份可以是User、Group或ServiceAccountRole/ClusterRole一組權(quán)限規(guī)則定義對哪些資源resources能做哪些動(dòng)作verbs如get、list、create、deleteRoleBinding/ClusterRoleBinding把Subject和Role綁起來權(quán)限才生效只有Role沒有Binding權(quán)限不生效只有Binding沒有匹配的Subject也不生效。1.2 應(yīng)用內(nèi)的身份是ServiceAccountPod里運(yùn)行的應(yīng)用訪問API Server時(shí)用的身份是ServiceAccount。每個(gè)命名空間有個(gè)默認(rèn)ServiceAccount也可以為工作負(fù)載指定專用的。所以當(dāng)一個(gè)應(yīng)用報(bào)Forbidden通常要查的是它用的ServiceAccount有沒有被綁定到包含所需權(quán)限的Role。1.3 Forbidden是授權(quán)結(jié)論不是資源不存在一個(gè)重要判斷Forbidden表示當(dāng)前身份沒有權(quán)限執(zhí)行這個(gè)動(dòng)作不代表目標(biāo)資源不存在也不代表資源本身有問題。這點(diǎn)第02篇也提過?？吹紽orbidden方向是查權(quán)限不是查資源。二、Role和ClusterRole的區(qū)別2.1 作用域不同對象作用域Role命名空間級只在所在命名空間內(nèi)有效ClusterRole集群級可用于集群范圍資源或被復(fù)用到各命名空間RoleBinding在某個(gè)命名空間內(nèi)授權(quán)ClusterRoleBinding集群范圍授權(quán)2.2 組合方式和作用域關(guān)鍵的組合規(guī)則RoleBinding Role在該命名空間內(nèi)授予Role的權(quán)限RoleBinding ClusterRole把ClusterRole的權(quán)限限定在該RoleBinding所在的命名空間生效。這是復(fù)用ClusterRole又不給全集群權(quán)限的常用方式ClusterRoleBinding ClusterRole全集群范圍授予權(quán)限影響面最大要謹(jǐn)慎一個(gè)常見誤解以為綁了ClusterRole就是全集群權(quán)限。其實(shí)如果用的是RoleBinding權(quán)限被限定在那個(gè)命名空間。作用域由Binding的類型決定。2.3 集群范圍資源只能用ClusterRole像Node、PersistentVolume、Namespace這類不屬于任何命名空間的資源只能通過ClusterRole加ClusterRoleBinding授權(quán)RoleBinding管不了。三、用can-i精確定位缺失權(quán)限kubectl auth can-i是權(quán)限排查的核心工具它直接回答某個(gè)身份能不能做某件事。3.1 查自己能不能kubectl auth can-i get pods-nnamespacekubectl auth can-i create deployments-nnamespace返回yes或no直接告訴你有沒有這條權(quán)限。3.2 查某個(gè)ServiceAccount能不能關(guān)鍵排查應(yīng)用權(quán)限時(shí)用--as模擬那個(gè)ServiceAccountkubectl auth can-i list configmaps\-nnamespace\--assystem:serviceaccount:namespace:serviceaccount這條命令直接回答這個(gè)ServiceAccount能不能list這個(gè)命名空間的configmaps是定位應(yīng)用Forbidden的最快方法。3.3 列出一個(gè)身份的所有權(quán)限kubectl auth can-i--list\-nnamespace\--assystem:serviceaccount:namespace:serviceaccount這會(huì)列出該身份在該命名空間能做的所有動(dòng)作一眼看出缺了什么。3.4 從錯(cuò)誤信息讀關(guān)鍵字段Forbidden錯(cuò)誤通常包含關(guān)鍵信息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缺的動(dòng)作list資源configmapsAPI組核心組空命名空間app有了這四項(xiàng)就知道要補(bǔ)什么權(quán)限而不是盲目加cluster-admin。四、RBAC排查決策樹報(bào)Forbidden │ ├─ 從錯(cuò)誤信息讀出身份、動(dòng)作、資源、API組、命名空間 │ ├─ 用can-i --as確認(rèn)這個(gè)身份到底缺哪條 │ └─ can-i --list看它現(xiàn)有全部權(quán)限 │ ├─ 查授權(quán)鏈哪一環(huán)斷了 │ ├─ 有沒有對應(yīng)的Role/ClusterRole定義了這條權(quán)限 │ ├─ 有沒有RoleBinding/ClusterRoleBinding把身份和Role綁上 │ ├─ 綁定的Subject是否正好是這個(gè)身份名字、命名空間、類型 │ └─ 作用域?qū)Σ粚oleBinding只在本命名空間 │ ├─ 只補(bǔ)缺失的最小權(quán)限不加cluster-admin │ └─ 補(bǔ)權(quán)限審計(jì)與治理先看現(xiàn)有的Role和Bindingkubectl get role,rolebinding-nnamespacekubectl get clusterrole,clusterrolebinding|grep關(guān)鍵字kubectl describe rolebindingbinding-name-nnamespacedescribe能看到Binding綁的是哪個(gè)Role、哪些Subject。五、C級生產(chǎn)化重建案例應(yīng)用升級后讀不到ConfigMap5.1 先說明哪些是真的哪些是重建的下面不是作者聲稱親歷的生產(chǎn)事故而是根據(jù)Kubernetes RBAC機(jī)制構(gòu)造的生產(chǎn)化重建。內(nèi)容證據(jù)屬性Subject、Role、Binding、ServiceAccount和can-i的機(jī)制Kubernetes官方機(jī)制應(yīng)用新增讀ConfigMap功能后報(bào)Forbidden機(jī)制一致的重建場景Namespace、資源名、身份和終端輸出為講解構(gòu)造的說明性信息ServiceAccount的Role缺少configmaps的list權(quán)限模擬根因不是作者生產(chǎn)記錄只補(bǔ)一條權(quán)限后驗(yàn)證恢復(fù)受控驗(yàn)證設(shè)計(jì)不聲稱已在當(dāng)前集群執(zhí)行所有輸出按真實(shí)對象關(guān)系編排但沒有連接實(shí)際集群采集讀者不能把下面的名稱或輸出引用為真實(shí)事故數(shù)據(jù)。5.2 現(xiàn)場卡片一個(gè)應(yīng)用升級后新增了讀取ConfigMap做動(dòng)態(tài)配置的功能上線后日志報(bào)Forbidden功能不可用。團(tuán)隊(duì)最初想直接給它的ServiceAccount加cluster-admin讓它先跑起來。重建的相對時(shí)間線相對時(shí)間觀察或動(dòng)作當(dāng)時(shí)能夠得出的結(jié)論T00應(yīng)用日志報(bào)configmaps forbidden存在權(quán)限問題原因未知T02有人提議加cluster-admin高風(fēng)險(xiǎn)先不做T04從錯(cuò)誤信息讀出缺list configmaps定位到具體動(dòng)作和資源T06can-i確認(rèn)ServiceAccount確實(shí)不能list configmaps主假設(shè)成立T驗(yàn)證只補(bǔ)list configmaps權(quán)限后驗(yàn)證單變量驗(yàn)證相對時(shí)間只表示排查順序不代表真實(shí)數(shù)值。5.3 從錯(cuò)誤信息讀關(guān)鍵字段應(yīng)用日志里的錯(cuò)誤configmaps is forbidden: User system:serviceaccount:app:config-reader cannot list resource configmaps in API group in the namespace app讀出四要素身份ServiceAccountconfig-reader命名空間app動(dòng)作list資源configmaps命名空間app方向明確是權(quán)限不是ConfigMap不存在。5.4 用can-i確認(rèn)NSappSAconfig-reader kubectl auth can-i list configmaps-n$NS\--assystem:serviceaccount:$NS:$SA機(jī)制一致的說明性輸出no確認(rèn)這個(gè)ServiceAccount確實(shí)不能list configmaps。再看它現(xiàn)有權(quán)限kubectl auth can-i--list-n$NS\--assystem:serviceaccount:$NS:$SA機(jī)制一致的說明性輸出Resources Non-Resource URLs Resource Names Verbs pods [] [] [get list watch] pods/log [] [] [get]它只有讀Pod的權(quán)限沒有configmaps。升級新增的讀ConfigMap功能超出了原有授權(quán)。5.5 查授權(quán)鏈kubectl get rolebinding-n$NS-owide kubectl describe role config-reader-role-n$NS機(jī)制一致的說明性輸出RoleBinding把config-reader綁到config-reader-role Role config-reader-role rules: Resources Verbs pods [get list watch] pods/log [get]Role里只有pods相關(guān)權(quán)限沒有configmaps。授權(quán)鏈?zhǔn)峭ǖ腂inding存在、Subject正確只是Role缺了這條規(guī)則。證據(jù)鏈錯(cuò)誤明確是list configmaps被拒 can-i確認(rèn)該SA不能list configmaps can-i --list顯示它只有pods權(quán)限 Role定義里沒有configmaps規(guī)則 升級新增了讀ConfigMap功能 強(qiáng)烈支持Role缺少configmaps的list權(quán)限這仍是主假設(shè)驗(yàn)證前不寫成根因已閉環(huán)。5.6 止損與單變量驗(yàn)證絕不加cluster-admin。單變量修正只給Role補(bǔ)上configmaps的讀權(quán)限不動(dòng)其他apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:name:config-reader-rolenamespace:apprules:-apiGroups:[]resources:[pods,pods/log]verbs:[get,list,watch]-apiGroups:[]# 新增這一條最小權(quán)限r(nóng)esources:[configmaps]verbs:[get,list,watch]驗(yàn)證kubectl apply-fconfig-reader-role.yaml kubectl auth can-i list configmaps-n$NS\--assystem:serviceaccount:$NS:$SA機(jī)制一致的說明性輸出yes補(bǔ)上這一條后can-i返回yes應(yīng)用功能恢復(fù)。只給了它需要的configmaps讀權(quán)限沒有擴(kuò)大到其他資源更沒有給集群級權(quán)限。這些輸出分別證明不同范圍的事實(shí)輸出能夠支持不能單獨(dú)證明can-i返回yes缺失權(quán)限已補(bǔ)上應(yīng)用其他動(dòng)作都夠只加了configmaps規(guī)則遵循了最小權(quán)限未來功能不再需要新權(quán)限應(yīng)用功能恢復(fù)該功能所需授權(quán)到位所有鏈路都正常5.7 根因閉環(huán)條件修正只有給Role補(bǔ)configmaps讀權(quán)限這一項(xiàng)主要變量。補(bǔ)后can-i從no變yes功能恢復(fù)。授權(quán)鏈其他環(huán)節(jié)Binding、Subject本來就對只是Role缺規(guī)則。沒有使用cluster-admin或擴(kuò)大到無關(guān)資源。應(yīng)用只拿到它需要的權(quán)限符合最小權(quán)限。如果補(bǔ)了還報(bào)Forbidden就檢查是不是API組或資源名寫錯(cuò)、命名空間不對、或者有多個(gè)同名Role/Binding混淆。六、最小權(quán)限的設(shè)計(jì)和治理層次動(dòng)作關(guān)鍵邊界精確定位從錯(cuò)誤讀四要素用can-i確認(rèn)Forbidden是授權(quán)結(jié)論不是資源不存在最小授權(quán)只補(bǔ)缺失的資源和動(dòng)作絕不用cluster-admin圖省事作用域控制優(yōu)先RoleBinding限定命名空間慎用ClusterRoleBinding集群級授權(quán)影響面最大專用身份為工作負(fù)載用專用ServiceAccount不共用默認(rèn)便于隔離和審計(jì)審計(jì)定期審查誰有什么權(quán)限回收多余授權(quán)權(quán)限只增不減會(huì)失控治理RBAC變更走評審納入版本管理權(quán)限變更可追溯一個(gè)核心原則權(quán)限應(yīng)該按需最小授予而不是先給大權(quán)限再想著收。收權(quán)限比給權(quán)限難得多因?yàn)榕掠绊憳I(yè)務(wù)。所以一開始就最小化。七、權(quán)限排查清單定位 [ ] 從Forbidden錯(cuò)誤讀出身份、動(dòng)作、資源、API組、命名空間 [ ] 用can-i --as確認(rèn)該身份缺哪條 [ ] 用can-i --list看它現(xiàn)有全部權(quán)限 查授權(quán)鏈 [ ] 有沒有Role/ClusterRole定義了這條權(quán)限 [ ] 有沒有Binding把身份和Role綁上 [ ] 綁定的Subject名字、命名空間、類型是否完全匹配 [ ] 作用域?qū)Σ粚oleBinding只在本命名空間集群資源要ClusterRole 修復(fù) [ ] 只補(bǔ)缺失的最小權(quán)限 [ ] 沒有使用cluster-admin [ ] 用專用ServiceAccount而非默認(rèn) [ ] 變更納入版本管理和審計(jì)八、監(jiān)控與治理8.1 監(jiān)控與審計(jì)什么誰綁定了cluster-admin或高權(quán)限ClusterRoleServiceAccount的權(quán)限范圍授權(quán)變更記錄審計(jì)日志Forbidden錯(cuò)誤的頻率和來源長期未使用的高權(quán)限身份8.2 治理原則按需最小授權(quán)一開始就不給多余權(quán)限工作負(fù)載用專用ServiceAccount不共用默認(rèn)SA優(yōu)先用RoleBinding限定命名空間ClusterRoleBinding嚴(yán)格評審RBAC配置納入版本管理變更走評審定期審查和回收多余權(quán)限尤其是cluster-admin九、常見誤區(qū)誤區(qū)1報(bào)Forbidden就加cluster-admin權(quán)限失控一旦被攻破影響整個(gè)集群應(yīng)只補(bǔ)缺失的最小權(quán)限。誤區(qū)2把Forbidden當(dāng)成資源不存在Forbidden是授權(quán)結(jié)論方向是查權(quán)限不是查資源。誤區(qū)3以為綁ClusterRole就是全集群權(quán)限RoleBinding引用ClusterRole時(shí)權(quán)限被限定在該命名空間。誤區(qū)4集群資源用RoleBinding授權(quán)Node、PV等集群資源只能用ClusterRole加ClusterRoleBinding。誤區(qū)5所有應(yīng)用共用默認(rèn)ServiceAccount不利于隔離和審計(jì)應(yīng)為工作負(fù)載用專用SA。誤區(qū)6只加權(quán)限不回收權(quán)限只增不減會(huì)逐漸失控要定期審查。誤區(qū)7不用can-i靠猜can-i能精確回答某身份能不能做某事比猜快得多。誤區(qū)8忽略Subject的精確匹配Subject的名字、命名空間、類型任一不符綁定都不生效。十、面試怎么說60秒版本RBAC報(bào)Forbidden我絕不直接加cluster-admin。先從錯(cuò)誤信息讀出身份、動(dòng)作、資源、API組和命名空間這幾要素Forbidden是授權(quán)結(jié)論不是資源不存在。然后用kubectl auth can-i加–as模擬那個(gè)ServiceAccount精確確認(rèn)缺哪條can-i --list看它現(xiàn)有全部權(quán)限。再查授權(quán)鏈有沒有Role定義這條權(quán)限、有沒有Binding綁上、Subject是否完全匹配、作用域?qū)Σ粚?。最后只補(bǔ)缺失的最小權(quán)限用RoleBinding限定命名空間絕不擴(kuò)大。RBAC是安全配置權(quán)限按需最小授予一開始就別給多。3分鐘場景版本假設(shè)應(yīng)用升級后報(bào)configmaps forbidden。我先從錯(cuò)誤讀出是ServiceAccount config-reader不能list configmaps方向是權(quán)限不是ConfigMap本身。用can-i --as模擬這個(gè)SA確認(rèn)返回no再用can-i --list看到它只有pods權(quán)限沒有configmaps因?yàn)樯壭略龅淖x配置功能超出了原授權(quán)。查Role發(fā)現(xiàn)只定義了pods規(guī)則。根因是Role缺configmaps的list權(quán)限。我不會(huì)加cluster-admin而是只給Role補(bǔ)一條configmaps的get/list/watchapply后can-i返回yes功能恢復(fù)。這樣應(yīng)用只拿到它需要的權(quán)限符合最小權(quán)限原則。這體現(xiàn)了RBAC排查的核心精確定位到缺哪一條只補(bǔ)那一條而不是用大權(quán)限掩蓋。十一、延伸問答1. Forbidden一定是權(quán)限問題嗎是。Forbidden表示當(dāng)前身份沒權(quán)限執(zhí)行該動(dòng)作不代表資源不存在。2. can-i怎么查ServiceAccount用--assystem:serviceaccount:命名空間:名字模擬該身份。3. Role和ClusterRole區(qū)別Role命名空間級ClusterRole集群級或可復(fù)用到各命名空間集群資源只能用ClusterRole。4. 綁了ClusterRole就是全集群權(quán)限嗎不一定。RoleBinding引用ClusterRole時(shí)權(quán)限限定在該命名空間作用域由Binding類型決定。5. 為什么不能隨便加cluster-admin權(quán)限失控被攻破或出bug影響整個(gè)集群應(yīng)只補(bǔ)最小權(quán)限。6. 應(yīng)用用什么身份訪問APIServiceAccount建議為工作負(fù)載用專用SA而非默認(rèn)。7. 補(bǔ)了權(quán)限還報(bào)Forbidden怎么辦檢查API組、資源名、命名空間是否寫對Subject是否精確匹配有無同名對象混淆。8. RBAC怎么治理按需最小授權(quán)、專用SA、優(yōu)先RoleBinding、納入版本管理、定期審查回收。小結(jié)RBAC授權(quán)鏈?zhǔn)荢ubject通過Binding關(guān)聯(lián)Role缺任一環(huán)權(quán)限都不生效。Forbidden是授權(quán)結(jié)論不是資源不存在。Role命名空間級ClusterRole集群級作用域由Binding類型決定。RoleBinding引用ClusterRole時(shí)權(quán)限限定在本命名空間。用can-i加–as精確定位某身份缺哪條權(quán)限。只補(bǔ)缺失的最小權(quán)限絕不加cluster-admin。工作負(fù)載用專用ServiceAccount便于隔離和審計(jì)。權(quán)限按需最小授予定期審查回收納入版本管理。下一篇預(yù)告下一篇進(jìn)入Kubernetes集群無中斷升級。我們會(huì)講清API兼容檢查、控制面和節(jié)點(diǎn)升級順序、PDB和節(jié)點(diǎn)驅(qū)逐、驗(yàn)證與回退并整理一份升級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