प्रॉम्प्ट और दायरा
आप enforcing मोड में SELinux चलाने वाले Linux नोड्स पर एक मल्टी-टेनेंट Kubernetes क्लस्टर संचालित करते हैं। प्लेटफ़ॉर्म CSI वॉल्यूम का उपयोग करता है, और कुछ वर्कलोड एक वॉल्यूम साझा करते हैं। टीम v1.36 में अपग्रेड करने की योजना बना रही है। यह माने बिना कि प्रत्येक नोड पर SELinux सक्षम है, संगतता जांच, एक कैनरी रोलआउट, ऑब्जर्वेबिलिटी और रोलबैक डिज़ाइन करें।
इंटरव्यूअर क्या जांच रहा है
इंटरव्यूअर चाहता है कि आप SELinux नोड्स को सामान्य नोड्स से अलग करें, माउंट संदर्भ और रिकर्सिव रीलेबलिंग के बीच अंतर स्पष्ट करें, और जब प्रिविलेज्ड और अनप्रिविलेज्ड Pods एक वॉल्यूम साझा करते हैं तो जोखिमों की पहचान करें। एक बेहतरीन उत्तर में CSI ड्राइवर, Pod securityContext, स्टार्टअप लेटेंसी, डेटा एक्सेस, एडमिशन सीमाएं और वर्ज़न-आधारित रोलबैक भी शामिल होते हैं।
पहले स्पष्ट करने योग्य प्रश्न
- कौन से नोड्स enforcing हैं, और कौन से CSI ड्राइवर और फ़ाइल सिस्टम समर्थित दायरे में हैं?
- क्या साझा स्टोरेज एक अनिवार्य व्यावसायिक सीमा है, या क्या वॉल्यूम को विभाजित किया जा सकता है या डेटा का स्पष्ट रूप से आदान-प्रदान किया जा सकता है?
- क्या माइग्रेशन स्टार्टअप लेटेंसी, टेनेंट आइसोलेशन, वर्कलोड निरंतरता, या किसी स्पष्ट ट्रेड-ऑफ को अनुकूलित कर रहा है?
- क्या डिप्लॉय किया गया वर्ज़न एक स्पष्ट लेबलिंग नीति की अनुमति देता है, और रोलबैक विंडो तथा साक्ष्य-प्रतिधारण आवश्यकताएं क्या हैं?
30-सेकंड का उत्तर
“मैं सबसे पहले नोड SELinux मोड, CSI ड्राइवर, वॉल्यूम प्रकार और शेयरिंग संबंधों की सूची (इन्वेंट्री) बनाऊंगा। v1.36 सुधार समर्थित वॉल्यूम के लिए माउंट संदर्भों का उपयोग करता है, जिससे रिकर्सिव रीलेबलिंग लागत कम हो जाती है लेकिन साझा वॉल्यूम के लिए एक्सेस परिणाम संभावित रूप से बदल सकते हैं। मैं विस्तार करने से पहले एक अलग नोड पूल में समकक्ष वर्कलोड चलाऊंगा, माउंट, लेबल, रीड और राइट, स्टार्टअप लेटेंसी और डिनायल लॉग की जांच करूंगा। यदि कोई सुरक्षा उपाय (गार्डरेल) विफल होता है, तो मैं नए वर्कलोड को रोक दूंगा, चल रहे Pods और साक्ष्यों को सुरक्षित रखूंगा, और डिप्लॉय किए गए वर्ज़न द्वारा समर्थित नीति का उपयोग करके रोलबैक करूंगा।”
चरण-दर-चरण समाधान
1. प्रभाव इन्वेंट्री बनाएं
प्रत्येक नोड के कर्नेल और SELinux स्थिति, enforcing या permissive मोड, Kubernetes वर्ज़न, CSI ड्राइवर वर्ज़न और वॉल्यूम प्रकार को रिकॉर्ड करें। प्रत्येक Pod के seLinuxOptions, पहचान, प्रिविलेज स्तर, माउंट पाथ और शेयरिंग संबंधों को निर्यात करें। बिना SELinux वाले नोड्स को समान व्यवहार निष्कर्ष में शामिल नहीं किया जाना चाहिए।
2. व्यवहार परिवर्तन को समझाएं
Kubernetes परिवर्तन SELinux वॉल्यूम-लेबलिंग सुधार को v1.36 में स्थिर बनाता है। समर्थित वॉल्यूम के लिए, सिस्टम प्रत्येक फ़ाइल को बार-बार (रिकर्सिवली) रीलेबल करने के बजाय माउंट संदर्भ का उपयोग कर सकता है। यह आमतौर पर बड़े वॉल्यूम के लिए स्टार्टअप कार्य को कम करता है, लेकिन यह धारणा कि उपयोग से पहले एक साझा वॉल्यूम को रीलेबल किया जाता है, तब विफल हो सकती है जब विभिन्न सुरक्षा डोमेन इसे एक्सेस करते हैं। एक सफल माउंट यह साबित नहीं करता है कि एप्लिकेशन डेटा पढ़ और लिख सकता है।
3. ड्राइवर और नीति सीमाओं की जांच करें
प्रत्येक CSI ड्राइवर के लिए, माउंट संदर्भों, फ़ाइल सिस्टम व्यवहार और माउंट-विकल्प प्रतिबंधों के समर्थन को सत्यापित करें। seLinuxChangePolicy, संबंधित फ़ीचर गेट्स और डिफ़ॉल्ट के लिए डिप्लॉय किए गए वर्ज़न के दस्तावेज़ों की जांच करें; बिना सत्यापन के किसी पुराने रिलीज़ से फ़ील्ड या स्विच की प्रतिलिपि न बनाएं। एडमिशन नीति को अनावश्यक प्रिविलेज को प्रतिबंधित करना चाहिए, साझा-वॉल्यूम सुरक्षा डोमेन को परिभाषित करना चाहिए और परिवर्तनों का ऑडिट करना चाहिए।
4. पुनरुत्पादित किए जा सकने वाले (रिप्रोड्यूसिबल) परीक्षण चलाएं
समान इमेज, UID/GID, securityContext और वॉल्यूम डेटा के साथ परीक्षण Pods तैयार करें। एक एकल Pod, समान-डोमेन शेयरिंग, प्रिविलेज्ड और अनप्रिविलेज्ड शेयरिंग, एक खाली वॉल्यूम और कई फ़ाइलों वाले वॉल्यूम को कवर करें। माउंट संदर्भ, फ़ाइल लेबल, रीड और राइट, रीस्टार्ट रिकवरी, विस्तार और CSI पुन: कनेक्टिविटी को सत्यापित करें। Pod निर्माण से लेकर Ready होने तक के प्रत्येक अंतराल को मापें।
5. कैनरी गार्डरेल्स जोड़ें
एक समर्पित नोड पूल और CSI StorageClasses का एक छोटा सेट बनाएं, और पुन: प्रयास करने योग्य (रीट्राइएबल) जॉब्स के साथ शुरुआत करें। कैनरी के दौरान असत्यापित सुरक्षा-डोमेन संयोजन को समान साझा वॉल्यूम न दें। डिनायल लॉग, माउंट विफलताओं, एप्लिकेशन अनुमति त्रुटियों, स्टार्टअप लेटेंसी और रीस्टार्ट सफलता के लिए सीमाएं (थ्रेसहोल्ड) निर्धारित करें। गार्डरेल सक्रिय होने पर विस्तार रोकें; SELinux या प्रिविलेज को व्यापक बनाकर समस्या को न छिपाएं।
6. साझा-वॉल्यूम जोखिम को संभालें
जब कोई वॉल्यूम प्रिविलेज्ड और अनप्रिविलेज्ड Pods द्वारा साझा किया जाता है, तो आगे बढ़ने से पहले वॉल्यूम को विभाजित करें या सुरक्षा डोमेन को एकीकृत करें। अपरिहार्य शेयरिंग के लिए, परिभाषित करें कि लेबलिंग का स्वामी कौन है, वॉल्यूम कब माउंट किया जाता है, और इसे कैसे पुनः प्राप्त किया जाता है, फिर एक वास्तविक एक्सेस मैट्रिक्स को मान्य करें। पुराने वॉल्यूम को केवल तभी हटाएं जब एप्लिकेशन रिकवरी साबित हो जाए, ताकि लेबलिंग की समस्या को डेटा हानि न समझ लिया जाए।
7. रोलबैक साक्ष्य सुरक्षित रखें
रोलबैक की शुरुआत कैनरी पूल में नए Pods के प्रवेश को रोककर होती है, जबकि चल रहे जॉब्स और इवेंट्स को सुरक्षित रखा जाता है। फिर डिप्लॉय किए गए वर्ज़न के लिए स्पष्ट रूप से समर्थित रिकर्सिव नीति या पुराने नोड पूल का चयन करें। फ़ीचर-गेट सेटिंग्स, नोड लेबल, CSI कॉन्फ़िगरेशन, Pod मैनिफ़ेस्ट और SELinux AVC डिनायल लॉग को बनाए रखें। रोलबैक के बाद उसी तुलना को फिर से चलाएं; केवल एक सफल डिप्लॉयमेंट कमांड रिकवरी का प्रमाण नहीं है।
मॉडल उत्तर
मैं माइग्रेशन को इन्वेंट्री, तुलना, कैनरी और रोलबैक के रूप में संरचित करूंगा। केवल enforcing मोड में उपलब्ध SELinux वाले Linux नोड्स ही दायरे में हैं, और CSI ड्राइवर समर्थन को डिप्लॉय किए गए Kubernetes वर्ज़न के आधार पर जांचा जाना चाहिए। v1.36 समर्थित वॉल्यूम के लिए माउंट संदर्भों का उपयोग करता है, जिससे रिकर्सिव रीलेबलिंग कम होती है लेकिन साझा वॉल्यूम और विभिन्न सुरक्षा डोमेन के लिए केंद्रित परीक्षणों की आवश्यकता होती है। परीक्षण खाली और बड़े वॉल्यूम, एक Pod, समान-डोमेन शेयरिंग और प्रिविलेज्ड/अनप्रिविलेज्ड शेयरिंग को कवर करते हैं; वे लेबल, एक्सेस, डिनायल लॉग, स्टार्टअप लेटेंसी और रीस्टार्ट रिकवरी की तुलना करते हैं। कैनरी पूल केवल रीट्राइएबल कार्य स्वीकार करता है। थ्रेसहोल्ड विफल होने पर विस्तार रुक जाता है, साक्ष्य सुरक्षित रहते हैं और नया कार्य एक दस्तावेजीकृत समर्थित पाथ पर वापस आ जाता है।
सामान्य गलतियां
- प्रत्येक नोड को SELinux नोड मानना → प्रभाव का दायरा गलत हो जाता है → नोड मोड और enforcing स्थिति के आधार पर विभाजित करें।
- केवल माउंट सफल होने का परीक्षण करना → रनटाइम एक्सेस अभी भी अस्वीकृत रहता है → वास्तविक पहचान, लेबल, रीड, राइट और रीस्टार्ट का परीक्षण करें।
- तुरंत प्रिविलेज को व्यापक बनाना → सुरक्षा सीमा का विस्तार होता है → सुरक्षा डोमेन, शेयरिंग संबंध या ड्राइवर कॉन्फ़िगरेशन को ठीक करें।
- CSI अंतरों को अनदेखा करना → कैनरी में एक वॉल्यूम क्लास विफल हो जाती है → ड्राइवर, फ़ाइल सिस्टम और वॉल्यूम प्रकार का मैट्रिक्स बनाएं।
- रोलबैक के दौरान प्रत्येक Pod को हटाना → साक्ष्य खो जाते हैं और जॉब्स रुक जाते हैं → नए ट्रैफ़िक को रोकें और स्थिति तथा लॉग को बनाए रखें।
अनुवर्ती प्रश्न और उत्तर
क्या permissive मोड में भी उसी माइग्रेशन की आवश्यकता है?
यह अभी भी इन्वेंट्री और परीक्षण के योग्य है क्योंकि permissive मोड सामान्य रूप से लागू किए बिना केवल अस्वीकृतियों (डिनायल्स) को रिकॉर्ड करता है। यह enforcing व्यवहार का प्रतिनिधित्व नहीं करता है, इसलिए रिलीज़ गेट्स को enforcing नोड्स पर पुनरुत्पादित किया जाना चाहिए।
आप लेबलिंग समस्या को CSI समस्या से कैसे अलग करते हैं?
वॉल्यूम प्रकार या ड्राइवर की अदला-बदली करते समय नोड, इमेज और सुरक्षा संदर्भ को स्थिर रखें। माउंट इवेंट्स, कर्नेल डिनायल्स, फ़ाइल लेबल और CSI लॉग की तुलना करें। समस्या को सुरक्षा-संदर्भ पाथ से केवल तभी जोड़ें जब यह सभी ड्राइवरों में समान रूप से पुनरुत्पादित हो।
क्या तेज़ स्टार्टअप सफलता साबित करने के लिए पर्याप्त है?
नहीं। प्रदर्शन केवल एक संकेत है। विभिन्न डोमेन के लिए एक्सेस मैट्रिक्स, रीस्टार्ट रिकवरी, विस्तार, रीकनेक्ट व्यवहार और ऑडिट साक्ष्य को भी रिलीज़ गेट्स को पूरा करना चाहिए।
क्या होगा यदि साझा वॉल्यूम एक ही सुरक्षा डोमेन का उपयोग नहीं कर सकते हैं?
वॉल्यूम को विभाजित करना या स्पष्ट डेटा-एक्सचेंज पाथ का उपयोग करना बेहतर है। यदि शेयरिंग अपरिहार्य है, तो प्लेटफ़ॉर्म को सुरक्षा-डोमेन और जीवनचक्र निर्णयों का स्वामित्व लेना चाहिए, और अनुमत Pod संयोजनों को लागू किया जाना चाहिए तथा रिग्रेशन-परीक्षण किया जाना चाहिए।