arrow_backफ़ील्ड नोट्स पर वापस जाएँ
DEVOPS प्रकाशित 7 Jul 2026

Applied Kubernetes Hardening: A Practical Playbook

Kubernetes क्लस्टर को हार्ड करने के लिए एक व्यावहारिक गाइड, जिसमें RBAC, पॉड सिक्योरिटी, नेटवर्क पॉलिसी और सप्लाई चेन कंट्रोल शामिल हैं।

Kubernetes डिफ़ॉल्ट रूप से फ्लेक्सिबिलिटी के साथ आता है, सिक्योरिटी के साथ नहीं। हर खुला पोर्ट, परमिसिव RBAC रोल और अनरेस्ट्रिक्टेड पॉड एक न्योता है। क्लस्टर को हार्ड करने का मतलब है उन गैप्स को सिस्टेमेटिकली बंद करना बिना उन वर्कलोड्स को तोड़े जो उन पर निर्भर हैं। यह एक चेकलिस्ट एक्सरसाइज नहीं है—यह एक चलमान डिसिप्लिन है जो आइडेंटिटी, नेटवर्क, वर्कलोड और सप्लाई चेन लेयर्स को छूता है।

Control Plane को पहले लॉक करें

API सर्वर किसी भी क्लस्टर में सबसे मूल्यवान टार्गेट है। अनोनिमस ऑथेंटिकेशन को डिसेबल करके और मजबूत ऑथेंटिकेशन मेथड्स को एनफोर्स करके शुरुआत करें—आपके आइडेंटिटी प्रोवाइडर के साथ OIDC इंटीग्रेशन स्टैटिक टोकन या ऐसे क्लाइंट सर्टिफिकेट्स के लिए बेहतर है जो कभी एक्सपायर नहीं होते। etcd डेटास्टोर को एक्सेस रेस्ट्रिक्ट करें, क्योंकि यह हर सीक्रेट और कॉन्फिग ऑब्जेक्ट को प्लेनटेक्स्ट में रखता है जब तक कि एनक्रिप्शन एट रेस्ट एनेबल न हो। KMS प्रोवाइडर का उपयोग करके सीक्रेट्स के लिए एनक्रिप्शन एनेबल करें बजाय base64 एनकोडिंग पर रिलाई करने के, जो जीरो वास्तविक सुरक्षा देता है। ऑडिट लॉगिंग को दिन एक से चालू किया जाना चाहिए; इसके बिना, आपके पास कोई फोरेन्सिक ट्रेल नहीं है जब कुछ गलत होता है।

RBAC: Least Privilege, सुविधा नहीं

प्रोडक्शन क्लस्टर्स में सबसे आम मिसकॉन्फिगरेशन अत्यधिक व्यापक RBAC बाइंडिंग हैं—cluster-admin को सर्विस अकाउंट्स को दिया जाता है जिन्हें सिर्फ एक नेमस्पेस में पॉड्स को पढ़ने की जरूरत है। वास्तविक जॉब फंक्शन्स के चारों ओर रोल्स बनाएं और उन्हें नेमस्पेसेज तक स्कोप करें जहां संभव हो। Role और ClusterRole डेफिनिशन्स में वाइल्डकार्ड वर्ब्स और रिसोर्सेज से बचें। kubectl auth can-i --list या rbac-lookup जैसे टूल्स के साथ रेगुलरली बाइंडिंग्स को ऑडिट करें प्रिविलेज क्रीप को कैच करने के लिए। सर्विस अकाउंट्स को ह्यूमन यूजर्स के समान स्क्रूटिनी की जरूरत है—जो पॉड्स को API एक्सेस की जरूरत नहीं है उनके लिए सर्विस अकाउंट टोकन्स की ऑटोमाउंटिंग को डिसेबल करें।

Pod Security: Compromise को मानें

Pod Security Admission (जिसने डेप्रीकेटेड PodSecurityPolicy की जगह ली) आपको नेमस्पेस लेवल पर बेसलाइन या रेस्ट्रिक्टेड प्रोफाइल्स को एनफोर्स करने देता है। न्यूनतम पर, प्रिविलेज्ड कंटेनर्स, होस्ट नेमस्पेस शेयरिंग और प्रिविलेज एस्केलेशन को डिसेलो करें। runAsNonRoot: true सेट करें और सभी Linux कैपेबिलिटीज को डिफ़ॉल्ट रूप से ड्रॉप करें, सिर्फ जो एक्सप्लिसिटली आवश्यक है उसे वापस जोड़ें। रीड-ओनली रूट फाइलसिस्टम्स एटैकर्स को एक चलमान कंटेनर में मैलिशस बाइनरीज लिखने से रोकते हैं। ये कंट्रोल्स महत्वपूर्ण हैं क्योंकि एक कंटेनर एस्केप या एक्सप्लॉइटेड एप्लिकेशन वल्नरेबिलिटी पूर्ण नोड कम्प्रोमाइज में ट्रांसलेट नहीं होनी चाहिए।

Network Policies अनिवार्य हैं

डिफ़ॉल्ट रूप से, Kubernetes क्लस्टर में हर पॉड हर दूसरे पॉड से बात कर सकता है। वह फ्लैट नेटवर्क मॉडल एटैकर्स के लिए लेटेरल मूवमेंट का स्वप्न है। NetworkPolicy रिसोर्सेज को इंप्लीमेंट करें डिफ़ॉल्ट-डेनी इनग्रेस और एग्रेस को एनफोर्स करने के लिए, फिर एक्सप्लिसिटली सिर्फ उन ट्रैफिक फ्लोज को अनुमति दें जिनकी आपकी एप्लिकेशन्स को जरूरत है। इसके लिए एक CNI प्लग-इन की जरूरत है जो वास्तव में NetworkPolicy एनफोर्समेंट को सपोर्ट करता है—Calico, Cilium और दूसरे इस रोल को भरते हैं क्योंकि बेस Kubernetes नेटवर्क मॉडल अपने आप में कुछ भी एनफोर्स नहीं करता। नेमस्पेसेज को ट्रस्ट बाउंड्री द्वारा सेगमेंट करना और पॉलिसीज को ऊपर लेयर करना आपको वास्तविक डिफेंस इन डेप्थ देता है।

Image और Supply Chain Integrity

हार्डेनिंग रनटाइम कॉन्फिगरेशन पर नहीं रुकता है—यह उससे शुरू होता है जो आप डिप्लॉय करते हैं। कंटेनर इमेजेज को नोन वल्नरेबिलिटीज के लिए स्कैन करें इससे पहले कि वे आपकी रजिस्ट्री तक पहुंचें, और एनफोर्स करें कि सिर्फ साइन्ड, वेरिफाइड इमेजेज आपकी क्लस्टर में रन कर सकती हैं Kyverno या OPA Gatekeeper जैसे एडमिशन कंट्रोलर्स का उपयोग करके। इमेज टैग्स को डाइजेस्ट्स में पिन करें बजाय latest जैसे म्यूटेबल टैग्स के, जो आपके अंतर्गत चुपचाप बदल सकते हैं। रजिस्ट्रीज को रेस्ट्रिक्ट करें जिनसे पॉड्स को पुल करने की अनुमति है, एक आम पाथ को बंद करके सप्लाई चेन अटैक्स के लिए जहां कम्प्रोमाइज्ड या टाइपोस्क्वेटेड इमेजेज प्रोडक्शन में स्लिप करती हैं।

Secrets Management Kubernetes डिफ़ॉल्ट्स से परे

नेटिव Kubernetes Secrets कुछ से बेहतर हैं, लेकिन वे एक सच्चा secrets management सॉल्यूशन नहीं हैं। एक एक्सटर्नल secrets manager को इंटीग्रेट करने पर विचार करें—Vault, AWS Secrets Manager या समान—और रनटाइम पर सीक्रेट्स को इंजेक्ट करें बजाय उन्हें क्लस्टर ऑब्जेक्ट्स के रूप में स्टोर करने के। यदि आपको नेटिव Secrets का उपयोग करना चाहिए, तो सुनिश्चित करें कि etcd एनक्रिप्शन एनेबल है और RBAC टाइटली रीड एक्सेस को रेस्ट्रिक्ट करता है, क्योंकि कोई भी पॉड या यूजर जिसके पास एक नेमस्पेस में सीक्रेट्स पर get परमिशन है क्रेडेंशियल्स को एक्सफिल्ट्रेट कर सकता है।

Continuous Verification, वन-टाइम सेटअप नहीं

हार्डेनिंग कॉन्फिगरेशन्स समय के साथ ड्रिफ्ट होती हैं क्योंकि नए वर्कलोड्स डिप्लॉय होते हैं और प्रायोरिटीज सिक्योरिटी से स्पीड की ओर शिफ्ट होती हैं। kube-bench जैसे टूल्स CIS Kubernetes Benchmark के विरुद्ध कंप्लायंस को चेक करते हैं, जबकि kube-hunter आपकी क्लस्टर के विरुद्ध एटैकर रीकोनिसंस को सिमुलेट कर सकता है। इन चेक्स को CI/CD पाइपलाइन्स में बेक करें ताकि मिसकॉन्फिगरेशन्स को प्रोडक्शन तक पहुंचने से पहले कैच किया जा सके बजाय एक इंसिडेंट रेस्पांस कॉल के दौरान।

Kubernetes हार्डेनिंग एक सिंगल सिल्वर-बुलेट कंट्रोल के बारे में कम है और आइडेंटिटी, नेटवर्क, वर्कलोड और सप्लाई चेन के विरुद्ध डिफेंसेज को लेयर करने के बारे में अधिक है—ताकि एक लेयर में एक फेलियर पूर्ण कम्प्रोमाइज में कैस्केड न हो। क्लाउड इंफ्रास्ट्रक्चर सिक्योरिटी पैटर्न्स और डिफेंसिव टूलिंग पर अधिक के लिए, Korra Studio के DEFENSE_GRID प्लेटफॉर्म पर संबंधित सेगमेंट्स को एक्सप्लोर करें।

AI सहायता से लिखा गया, माइकल पिल्च (CISSP), Korra Studio द्वारा समीक्षित और प्रकाशित।

आगे बढ़ने के लिए तैयार?

यह Korra Studio के ज्ञान आधार से एक नोट है — प्लेटफ़ॉर्म हर विषय को 1-टू-1 मेंटरिंग के साथ जोड़ता है।

मुफ़्त शुरू करेंarrow_forward