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