प्रॉम्प्ट और लागू संदर्भ
एक Kubernetes क्लस्टर में लेगेसी इमेजिस हैं जो कंटेनर के अंदर अभी भी UID 0 के रूप में चलती हैं। सिक्योरिटी टीम कंटेनर एस्केप के होस्ट प्रभाव को कम करने के लिए यूज़र नेमस्पेस चाहती है, जबकि बिज़नेस टीम वॉल्यूम ओनरशिप, hostPath, मॉनिटरिंग एजेंट्स, प्रिविलेज्ड कैपेबिलिटीज़ और पुराने नोड्स को लेकर चिंतित है। माइग्रेशन, वैलिडेशन, कैनरी, ऑब्ज़र्वेबिलिटी और रोलबैक प्लान डिज़ाइन करें।
यह एक सिस्टम-डिज़ाइन प्रश्न है। यहाँ मुख्य संकेत केवल hostUsers: false लिखने के बजाय आइसोलेशन को आइडेंटिटी, स्टोरेज, शेड्यूलिंग, पॉलिसी और ऑपरेशन्स से मैप करना है।
इंटरव्यूअर क्या मूल्यांकन करता है
- कंटेनर-रूट और होस्ट UID के बीच अंतर को समझाना, जिसमें कैपेबिलिटी स्कोप भी शामिल है।
- वॉल्यूम्स, होस्ट नेमस्पेस, CRI/OCI रनटाइम्स और Pod Security के बीच सीमाओं की पहचान करना।
- मौजूदा वर्कलोड्स को प्रभावित किए बिना कम्पैटिबिलिटी चेक और चरणबद्ध माइग्रेशन डिज़ाइन करना।
- सिक्योरिटी लाभ, परफॉर्मेंस कॉस्ट, SLOs, मेट्रिक्स और रोलबैक शर्तों को परिभाषित करना।
- माइग्रेशन के बाद एप्लिकेशन, डिबगिंग, मॉनिटरिंग और बैकअप के काउंटर-एग्जांपल्स को संभालना।
Kubernetes दस्तावेज़ v1.36 में यूज़र नेमस्पेस को स्टेबल और डिफ़ॉल्ट रूप से इनेबल्ड बताते हैं; एक Pod spec.hostUsers: false के साथ इसमें ऑप्ट-इन करता है। Amazon की SDE II सामग्री विश्वसनीयता, दक्षता, अनुकूलन और स्केलेबिलिटी के माध्यम से सिस्टम डिज़ाइन का मूल्यांकन करती है। यह प्रश्न सिक्योरिटी लाभ और ऑपरेशनल जोखिम को एक साथ मापने की आवश्यकता जोड़ता है।
स्पष्टीकरण के लिए प्रश्न
- क्या क्लस्टर केवल Linux-आधारित है, और क्या kubelet, CRI, OCI रनटाइम और कर्नेल वर्ज़न आवश्यकताओं को पूरा करते हैं?
- क्या वर्कलोड्स hostNetwork, hostPID, hostIPC, hostPath, डिवाइसेस, प्रिविलेज्ड कंटेनर्स या ऐसे मॉनिटरिंग एजेंट्स का उपयोग करते हैं जिन्हें होस्ट UIDs की आवश्यकता होती है?
- कौन से वॉल्यूम्स Pods के बीच साझा किए जाते हैं, और क्या मौजूदा फ़ाइल UIDs/GIDs मैप करने योग्य रेंज के अंदर हैं?
- क्या एप्लिकेशन को वास्तव में होस्ट रूट की आवश्यकता है, या केवल अपने कंटेनर के अंदर रूट सेमेंटिक्स की?
- क्या लक्ष्य एस्केप कंटेनमेंट है, Pod Security अनुपालन है, या कंटेनर-लोकल नेटवर्क एडमिनिस्ट्रेशन जैसी कोई विशिष्ट नेमस्पेस्ड कैपेबिलिटी है?
- क्या आप रोलबैक के लिए hostUsers=true टेम्पलेट को बनाए रखते हुए नेमस्पेस, नोड पूल या वर्कलोड के आधार पर कैनरी डिप्लॉयमेंट कर सकते हैं?
30-सेकंड उत्तर ढांचा
Linux, कर्नेल, CRI/OCI रनटाइम, होस्ट नेमस्पेस, वॉल्यूम्स और प्रिविलेज्ड कैपेबिलिटीज़ के लिए एक पात्रता मैट्रिक्स (eligibility matrix) बनाएं। केवल पात्र Pods के लिए hostUsers: false सेट करें। सत्यापित करें कि एप्लिकेशन की UID सेमेंटिक्स स्थिर बनी रहे जबकि होस्ट को एक मैप्ड, नॉन-प्रिविलेज्ड UID दिखाई दे। फ़ाइल एक्सेस, मॉनिटरिंग, नेटवर्किंग और डिबगिंग का परीक्षण करें, फिर वर्कलोड के अनुसार कैनरी डिप्लॉयमेंट करें। स्टार्टअप लेटेंसी, परमिशन एरर, OOMs, एस्केप कंट्रोल्स और बिज़नेस SLOs पर नज़र रखें; सीमाएं टूटने पर पुराने टेम्पलेट पर वापस लौटें।
चरण-दर-चरण विस्तृत उत्तर
1. आइसोलेशन मॉडल को समझाएं
एक यूज़र नेमस्पेस कंटेनर यूज़र्स को विभिन्न होस्ट UIDs और GIDs में मैप करता है। कंटेनर के अंदर रूट उस नेमस्पेस के भीतर आवश्यक ऑपरेशन्स कर सकता है, लेकिन उसकी कैपेबिलिटीज़ केवल वहीं मान्य होती हैं और होस्ट-रूट पावर प्रदान नहीं करती हैं। Kubernetes एक Pod को hostUsers: false के साथ ऑप्ट-इन करता है और एक नोड पर नॉन-ओवरलैपिंग होस्ट मैपिंग्स असाइन करता है।
यह कर्नेल आइडेंटिटी सीमा को बदलता है; यह पूरी तरह से एक सैंडबॉक्स नहीं है। seccomp, AppArmor या SELinux, नेटवर्क पॉलिसी, रीड-ओनली फ़ाइल सिस्टम, लीस्ट प्रिविलेज और पैच किए गए नोड्स का उपयोग जारी रखें। यूज़र नेमस्पेस एक सुरक्षा नियंत्रण है, हर एस्केप पाथ का संपूर्ण समाधान नहीं।
2. रनटाइम और नोड पात्रता की जाँच करें
प्रत्येक लक्षित नोड पर kubelet, CRI और OCI रनटाइम में यूज़र-नेमस्पेस सपोर्ट की पुष्टि करें। Kubernetes दस्तावेज़ containerd 2.0, CRI-O 1.25, runc 1.2 और crun 1.9 जैसे सपोर्ट की सूची देते हैं; डिप्लॉयमेंट्स को अभी भी कर्नेल, idmapped माउंट्स और डिस्ट्रिब्यूशन सेटिंग्स को सत्यापित करने की आवश्यकता होती है।
एडमिशन पॉलिसी उन नोड्स या कैपेबिलिटी कॉम्बिनेशन्स को अस्वीकार कर सकती है जो पात्र नहीं हैं। CI अंतिम Pod को रेंडर करता है और hostUsers, सिक्योरिटी संदर्भ, होस्ट नेमस्पेस और वॉल्यूम प्रकारों की जाँच करता है। रोलआउट से पहले, एक प्रोब Pod निर्माण, माउंट्स, रीस्टार्ट्स और नोड रीशेड्यूलिंग को वैलिडेट करता है।
3. वॉल्यूम्स और UID/GID का मूल्यांकन करें
Pod runAsUser, runAsGroup, और fsGroup अभी भी कंटेनर के अंदर के यूज़र का वर्णन करते हैं। वॉल्यूम परमिशन सेमेंटिक्स पहले की तरह उपयोग करने योग्य रहनी चाहिए, इसलिए केवल यूज़र नेमस्पेस सक्षम होने के कारण एप्लिकेशन्स को आमतौर पर व्यापक ओनरशिप रीराइट की आवश्यकता नहीं होती है।
मैप की गई UID/GID रेंज से बाहर की फ़ाइलें ओवरफ़्लो ID के रूप में दिखाई दे सकती हैं और राइट करने योग्य नहीं हो सकती हैं। माइग्रेशन से पहले ओनर्स, इनिट स्क्रिप्ट्स, शेयर्ड वॉल्यूम्स और बैकअप/रिस्टोर टूल्स को स्कैन करें। उस वर्कलोड के लिए यूज़र नेमस्पेस सक्षम करने से पहले इमेजिस या डेटा को ठीक करें।
4. निषिद्ध संयोजनों और पॉलिसी को संभालें
यूज़र नेमस्पेस सक्षम होने पर, एक Pod कुछ होस्ट नेमस्पेस जैसे hostNetwork, hostPID, या hostIPC का उपयोग नहीं कर सकता है। जिन वर्कलोड्स को होस्ट डिवाइसेस, प्रिविलेज्ड मोड या विशेष proc माउंट्स की आवश्यकता होती है, उन्हें अलग से समीक्षा की आवश्यकता होती है। Pod Security Standards चुनिंदा चेक्स को नियंत्रित तरीके से शिथिल कर सकते हैं, लेकिन यह हर अन्य पॉलिसी को हटाने की अनुमति नहीं है।
होस्ट-नेमस्पेस-निर्भर वर्कलोड्स को डिफर्ड (deferred) के रूप में चिह्नित करें और एक्सेप्शन अप्रूवल, कम्पेन्सेटिंग कंट्रोल्स और समाप्ति तिथि दर्ज करें। केवल एडमिशन पास करने के लिए फ़ील्ड्स को स्वचालित रूप से न हटाएं; यह एक कार्यात्मक विफलता को एक अदृश्य सुरक्षा डाउनग्रेड में बदल देता है।
5. परफॉर्मेंस, SLO और ऑब्ज़र्वेबिलिटी डिज़ाइन करें
Pod स्टार्टअप और वॉल्यूम-माउंट लेटेंसी, नोड CPU और मेमोरी, इन-कंटेनर परमिशन एरर्स, मॉनिटरिंग लॉस, बैकअप/रिस्टोर सफलता और रीस्टार्ट्स को ट्रैक करें। Idmapped माउंट्स बड़े वॉल्यूम्स पर रिकर्सिव chown से बच सकते हैं, लेकिन सैद्धांतिक दावों पर निर्भर रहने के बजाय वास्तविक कर्नेल, रनटाइम और फ़ाइल सिस्टम के साथ मापें।
लॉग्स और मेट्रिक्स को माइग्रेशन वर्ज़न, नोड पूल, इमेज और वॉल्यूम प्रकार के साथ टैग करें। सुरक्षा संकेतों में अस्वीकृत एस्केप टेस्ट, असफल प्रिविलेज्ड ऑपरेशन्स और Pod Security उल्लंघन शामिल हैं; व्यावसायिक संकेतों में रिक्वेस्ट एरर्स, लेटेंसी और डेटा अखंडता शामिल हैं।
6. चरणबद्ध माइग्रेशन और रोलबैक
उन स्टेटलेस वर्कलोड्स से शुरुआत करें जो किसी होस्ट नेमस्पेस का उपयोग नहीं करते हैं और सरल वॉल्यूम्स का उपयोग करते हैं, फिर स्टेटफुल सेवाओं तक विस्तार करें। प्रत्येक बैच के लिए hostUsers=true टेम्पलेट का हैश रखें। परमिशन एरर्स, स्टार्टअप रिग्रेशन, बिज़नेस एरर रेट, वॉल्यूम रीड/राइट विफलताओं या नोड एविक्शन्स पर स्वचालित रूप से रोकें।
रोलबैक केवल एक फ़ील्ड बदलने से कहीं अधिक है: सत्यापित करें कि वॉल्यूम माउंट्स, runAs यूज़र्स, मॉनिटरिंग एजेंट्स और एडमिशन आउटपुट पुराने रूप में वापस आ जाएं। एक ही विंडो में रनटाइम, कर्नेल और इमेज को अपग्रेड करने से बचें ताकि विफलताओं के कारणों की पहचान की जा सके।
7. सुरक्षा लाभ और अवशिष्ट जोखिम बताएं
यूज़र नेमस्पेस कंटेनर-रूट एस्केप के होस्ट प्रभाव को कम करते हैं और उन वर्कलोड्स के लिए एक संकीर्ण डोमेन प्रदान करते हैं जिन्हें कंटेनर-लोकल प्रशासन की आवश्यकता होती है। वे एप्लिकेशन सीक्रेट्स, क्रॉस-कंटेनर लॉजिक हमलों, खराब नेटवर्क नीतियों या पहले से प्रभावित शेयर्ड सर्विस की रक्षा नहीं करते हैं।
सुरक्षा समीक्षा में शेष hostPath, डिवाइसेस, कैपेबिलिटीज़, कर्नेल इंटरफेस और सर्विस अकाउंट्स को सूचीबद्ध किया जाना चाहिए, फिर seccomp, SELinux, नोड आइसोलेशन और वल्नेरेबिलिटी पैचिंग को डिफ़ेंस-इन-डेप्थ में संयोजित करना चाहिए।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं एक पात्रता मैट्रिक्स बनाऊंगा: लक्षित नोड्स Linux होने चाहिए और kubelet, CRI/OCI रनटाइम, कर्नेल और फ़ाइल सिस्टम के लिए यूज़र-नेमस्पेस आवश्यकताओं को पूरा करते होने चाहिए। मैं hostNetwork, hostPID, hostIPC, प्रिविलेज्ड डिवाइसेस, या होस्ट UID मान्यताओं का उपयोग करने वाले Pods को बाहर कर दूंगा। पात्र टेम्पलेट्स hostUsers: false सेट करते हैं; परीक्षण पुष्टि करते हैं कि कंटेनर UID/GID सेमेंटिक्स सही बनी रहती है जबकि होस्ट एक अनप्रिविलेज्ड मैपिंग देखता है।
रोलआउट से पहले मैं ओवरफ़्लो-ID व्यवहार सहित वॉल्यूम ओनर्स, इनिट स्क्रिप्ट्स, शेयर्ड वॉल्यूम्स और बैकअप/रिस्टोर पाथ्स को स्कैन करूंगा। एक प्रोब Pod निर्माण, माउंट्स, रीस्टार्ट्स और रीशेड्यूलिंग को वैलिडेट करता है। कैनरी डिप्लॉयमेंट्स स्टार्टअप और माउंट लेटेंसी, परमिशन एरर्स, बिज़नेस SLO, एविक्शन्स, मॉनिटरिंग और बैकअप संकेतों को मापते हैं। तत्काल रोलबैक के लिए पुराना टेम्पलेट हैश उपलब्ध रहता है।
मैं यूज़र नेमस्पेस को एक डिफ़ेंस-इन-डेप्थ लेयर के रूप में मानूंगा और seccomp, SELinux/AppArmor, नेटवर्क पॉलिसी, लीस्ट प्रिविलेज और नोड पैचिंग को बनाए रखूंगा। सुरक्षा लाभ, परफॉर्मेंस कॉस्ट और डिफर्ड वर्कलोड्स माइग्रेशन चेकलिस्ट का हिस्सा हैं; केवल एक फ़ील्ड सेट करना अपने आप में माइग्रेशन नहीं है।
सामान्य गलतियाँ
- Linux, रनटाइम, कर्नेल और वॉल्यूम की स्थितियों की जाँच किए बिना केवल
hostUsers: falseलिखना। - यह कहना कि कंटेनर रूट एक साधारण यूज़र बन जाता है और दो UID अर्थों की अनदेखी करना।
- यूज़र नेमस्पेस को हर एस्केप, प्रिविलेज या नेटवर्क जोखिम के लिए एक स्वचालित समाधान मानना।
- hostNetwork, hostPID, hostIPC, hostPath, डिवाइस और proc-माउंट सीमाओं को नज़रअंदाज़ करना।
- प्रत्येक वॉल्यूम पर रिकर्सिव chown करना या ओवरफ़्लो UID/GID फ़ाइलों को स्कैन करने में विफल रहना।
- रनटाइम, कर्नेल और इमेज को एक साथ अपग्रेड करना, जिससे विफलताओं का कारण जानना असंभव हो जाता है।
- कोई पुराना टेम्पलेट, स्वचालित स्टॉप शर्त या सत्यापन योग्य रोलबैक न होना।
फॉलो-अप प्रश्न और उत्तर
कौन सा Kubernetes वर्ज़न यूज़र नेमस्पेस को स्टेबल बनाता है?
आधिकारिक दस्तावेज़ Kubernetes v1.36 में इस सुविधा को स्टेबल और डिफ़ॉल्ट रूप से इनेबल्ड चिह्नित करते हैं; Pods अभी भी spec.hostUsers: false के साथ ऑप्ट-इन करते हैं। रोलआउट से पहले वास्तविक क्लस्टर और नोड वर्ज़न्स को सत्यापित करें।
क्या कंटेनर रूट अभी भी कैपेबिलिटीज़ का उपयोग कर सकता है?
यह उस यूज़र नेमस्पेस के अंदर मान्य कैपेबिलिटीज़ का उपयोग कर सकता है, लेकिन वे कैपेबिलिटीज़ स्वचालित रूप से होस्ट प्रिविलेज नहीं बन जाती हैं। लीस्ट प्रिविलेज, seccomp और LSM कंट्रोल्स लागू करें।
क्या मौजूदा PVC अनुमतियाँ पूरी तरह टूट जाएंगी?
कंटेनर UID/GID सेमेंटिक्स आमतौर पर स्थिर रहती हैं, इसलिए व्यापक ओनरशिप रीराइट की आवश्यकता नहीं होती है। मैपिंग रेंज से बाहर की फ़ाइलें ओवरफ़्लो IDs बन सकती हैं और उन्हें स्कैन और रिपेयर करने की आवश्यकता होती है।
इसे hostNetwork के साथ क्यों नहीं जोड़ा जा सकता है?
यूज़र नेमस्पेस आइसोलेटेड यूज़र और रिसोर्स सीमाओं पर निर्भर करते हैं, और कुछ होस्ट-नेमस्पेस संयोजन उस आइसोलेशन को कमजोर कर सकते हैं, इसलिए Kubernetes उन्हें अस्वीकार करता है। होस्ट-नेटवर्क वर्कलोड्स को कम्पेन्सेटिंग कंट्रोल्स के साथ स्पष्ट अपवाद के रूप में रखें।
आप कैसे साबित करेंगे कि जोखिम कम हुआ है?
एस्केप-आइसोलेशन और प्रिविलेज्ड-ऑपरेशन टेस्ट चलाएं, होस्ट UID, कैपेबिलिटीज़ और एक्सेस स्कोप का निरीक्षण करें, और बिज़नेस एरर्स, स्टार्टअप लेटेंसी और वॉल्यूम अखंडता की तुलना करें। केवल Pod निर्माण की सफलता ही इसका प्रमाण नहीं है।
किन वर्कलोड्स को इंतज़ार करना चाहिए?
होस्ट नेमस्पेस, विशेष डिवाइसेस, प्रिविलेज्ड कर्नेल इंटरफेस या अनरिपेयरेबल वॉल्यूम UID/GID लेआउट की आवश्यकता वाले वर्कलोड्स को टालें (defer करें)। कारण, कम्पेन्सेटिंग कंट्रोल्स और पुनर्मूल्यांकन तिथि दर्ज करें।