प्रकाशित: 2026-03-04
KENSAI की क्लाउड सुरक्षा शोध टीम ने 12,000 प्रोडक्शन Kubernetes क्लस्टर का विश्लेषण किया यूरोपीय एंटरप्राइज़ में, और पाया कि 58% में RBAC (Role-Based Access Control) मिसकॉन्फ़िगरेशन इतने गंभीर हैं कि वे लेटरल मूवमेंट और क्लस्टर-एडमिन तक विशेषाधिकार-वृद्धि की अनुमति देते हैं। पाँच सबसे ख़तरनाक पैटर्न — वाइल्डकार्ड परमिशन, डिफ़ॉल्ट सर्विस-अकाउंट दुरुपयोग, अत्यधिक ClusterRoleBinding, पॉड-निर्माण अधिकारों के ज़रिए नेमस्पेस-एस्केप, और प्रिविलेज्ड पॉड में टोकन माउंटिंग — ज़्यादातर डिप्लॉयमेंट में मौजूद हैं। ज़्यादातर संगठन शुरुआती सेटअप के बाद RBAC पॉलिसी का ऑडिट नहीं करते।
⚡ अगर कोई हमलावर स्कैन किए गए 58% क्लस्टर में किसी भी पॉड को भंग करता है, तो वह सिर्फ़ RBAC मिसकॉन्फ़िगरेशन का उपयोग करके मिनटों के भीतर पूर्ण क्लस्टर-एडमिन तक विशेषाधिकार बढ़ा सकता है।
सबसे व्यापक मिसकॉन्फ़िगरेशन: 23% क्लस्टर में वाइल्डकार्ड (*) verb या resource वाले कस्टम ClusterRole हैं। टीमें cluster-admin रोल को शुरुआती बिंदु के रूप में कॉपी करती हैं और उसे सीमित करना भूल जाती हैं। ऐसे रोल से जुड़े सर्विस-अकाउंट वाले एक अकेले पॉड की हर नेमस्पेस के हर संसाधन तक असीमित पहुँच होती है — सीक्रेट, configmap, नोड, और ख़ुद API सर्वर।
# Dangerous: Wildcard ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: devops-tools
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"] # ← Full cluster-admin equivalent
हर Kubernetes नेमस्पेस में एक default सर्विस-अकाउंट होता है जो स्पष्ट रूप से अक्षम न होने तक पॉड में स्वचालित रूप से माउंट हो जाता है। 41% क्लस्टर में, कम से कम एक नेमस्पेस में डिफ़ॉल्ट सर्विस-अकाउंट को उच्च परमिशन दी गई है — अक्सर इसलिए क्योंकि किसी ऑपरेटर ने डिबगिंग के दौरान एक त्वरित kubectl create rolebinding चलाया और उसे कभी साफ़ नहीं किया। उस नेमस्पेस में किसी भी पॉड में RCE हासिल करने वाले हमलावर तुरंत उन परमिशन को विरासत में पा लेते हैं।
34% क्लस्टर में 10 से ज़्यादा कस्टम ClusterRoleBinding हैं — ऐसे बाइंडिंग जो सभी नेमस्पेस में परमिशन देते हैं। कई व्यापक रोल को समूहों से बाँधते हैं जैसे system:authenticated या system:serviceaccounts, जो प्रभावी रूप से क्लस्टर में हर ऑथेंटिकेटेड यूज़र या हर सर्विस-अकाउंट को उच्च एक्सेस दे देता है।
जिन यूज़र के पास किसी भी नेमस्पेस में create pods permission है, वे होस्ट फ़ाइलसिस्टम माउंट कर सकते हैं, प्रिविलेज्ड कंटेनर चला सकते हैं, या उस नेमस्पेस में किसी भी सर्विस-अकाउंट के साथ पॉड बना सकते हैं। 29% क्लस्टर में,डेवलपरों के पास Pod Security Standards लागू किए बिना पॉड-निर्माण अधिकार हैं — जिससे अंतर्निहित नोड तक तुच्छ कंटेनर-एस्केप संभव हो जाता है।
Kubernetes डिफ़ॉल्ट रूप से सर्विस-अकाउंट टोकन को पॉड में माउंट करता है। जब इसे प्रिविलेज्ड पॉड-स्पेक या होस्ट नेटवर्क एक्सेस के साथ जोड़ा जाता है, तो हमलावर टोकन चुरा सकते हैं और API सर्वर से ऑथेंटिकेट कर सकते हैं क्लस्टर के बाहर से। स्कैन किए गए क्लस्टरों में से केवल 12% ने उन वर्कलोड पर जिन्हें API एक्सेस की ज़रूरत नहीं automountServiceAccountToken: false सेट किया है।
get secrets permission थी — हमलावर ने 4 मिनटों के भीतर डेटाबेस क्रेडेंशियल्स, API की, और TLS सर्टिफ़िकेट निकाल लिए।
विश्लेषित किए गए प्रोडक्शन Kubernetes क्लस्टरों में से आधे से ज़्यादा में कम से कम एक RBAC मिसकॉन्फ़िगरेशन है जो भंग किए गए पॉड से क्लस्टर-एडमिन स्तर के एक्सेस तक विशेषाधिकार-वृद्धि को सक्षम बना सकता है।
मिसकॉन्फ़िगर्ड क्लस्टरों के ख़िलाफ़ पेनेट्रेशन टेस्ट में, शुरुआती पॉड-कॉम्प्रोमाइज़ से पूर्ण क्लस्टर-एडमिन एक्सेस तक का औसत समय 3.2 मिनट था। इस जैसे स्वचालित टूल peirates और kubeletctl इसे तुच्छ बना देते हैं।
वाइल्डकार्ड रीड-परमिशन वाले क्लस्टरों ने सभी नेमस्पेस में औसतन 847 Kubernetes सीक्रेट उजागर किए — जिसमें डेटाबेस क्रेडेंशियल्स, API की, TLS सर्टिफ़िकेट, और क्लाउड-प्रोवाइडर IAM टोकन शामिल हैं।
ज़्यादातर संगठन क्लस्टर-प्रोविज़निंग के दौरान एक बार RBAC कॉन्फ़िगर करते हैं और फिर कभी इसकी समीक्षा नहीं करते। महीनों में रोल-बाइंडिंग जमा होती जाती हैं क्योंकि टीमें डिबगिंग, CI/CD पाइपलाइन, और मॉनिटरिंग के लिए परमिशन जोड़ती हैं — और उन्हें कभी हटाती नहीं।
KENSAI के Kubernetes सुरक्षा मॉड्यूल में अब स्वचालित RBAC विश्लेषण शामिल है जो विशेषाधिकार-वृद्धि पथों की पहचान करने के लिए आपके क्लस्टर में हर सर्विस-अकाउंट, रोल, और बाइंडिंग को मैप करता है। स्कैनर परमिशन-चेन का एक विज़ुअल ग्राफ़ जनरेट करता है और किसी भी भंग वर्कलोड से क्लस्टर-एडमिन तक के सबसे छोटे रास्ते को हाइलाइट करता है।
हर वर्कलोड का अपना समर्पित सर्विस-अकाउंट होना चाहिए जिसमें केवल वे परमिशन हों जिनकी उसे वास्तव में ज़रूरत है। जब नेमस्पेस-स्कोप्ड Role काफ़ी हों तो ClusterRole बाइंड करने से बचें। automountServiceAccountToken: false उन पॉड के लिए उपयोग करें जिन्हें Kubernetes API एक्सेस की ज़रूरत नहीं — जो ज़्यादातर एप्लिकेशन वर्कलोड हैं।
Kubernetes Pod Security Standards (PSS) को restricted स्तर पर लागू करने से पॉड root के रूप में चलने, होस्ट-पाथ माउंट करने, या प्रिविलेज्ड मोड इस्तेमाल करने से रुकते हैं। इन्हें Pod Security Admission का उपयोग करके नेमस्पेस-स्तर पर लागू करें। यह RBAC परमिशन अत्यधिक व्यापक होने पर भी कंटेनर-एस्केप वेक्टर को ख़त्म कर देता है।
लागू करें: तिमाही RBAC ऑडिट। सभी ClusterRoleBinding की समीक्षा करें, गए हुए टीम-सदस्यों या डीकमीशंड सर्विस से पुराने बाइंडिंग की पहचान करें, और सत्यापित करें कि किसी भी सर्विस-अकाउंट के पास आवश्यकता से ज़्यादा परमिशन नहीं है। KENSAI निरंतर ड्रिफ़्ट-डिटेक्शन के साथ इसे स्वचालित कर सकता है।
kubectl get clusterroles -o json | jq '.items[] | select(.rules[]?.verbs[]? == "*")'automountServiceAccountToken: false सेट करें जिन्हें API एक्सेस की ज़रूरत नहींrestricted PSS लागू करेंkubectl get clusterrolebindings -o wide — व्यापक समूहों से बंधी किसी भी चीज़ को फ़्लैग करेंkensai scan --k8s-rbac चलाएँ। रिपोर्ट में एक विशेषाधिकार-वृद्धि ग्राफ़, हर फ़ाइंडिंग के लिए विशिष्ट सुधार-कदम, और निर्देश के अधीन संगठनों के लिए NIS2 अनुपालन-मैपिंग शामिल है।
*) verb और resource हटाएँsystem:authenticated या system:serviceaccountsautomountServiceAccountToken: false सेट करेंrestricted स्तर पर Pod Security Standards लागू करें🛡️ क्या आपकी वेबसाइट सुरक्षित है?
हमलावरों से पहले भेद्यताएँ खोजें।
अपनी वेबसाइट निःशुल्क स्कैन करें →