समस्या और संदर्भ
Kubernetes ValidatingAdmissionPolicy API अनुरोधों के विरुद्ध CEL एक्सप्रेशन्स का मूल्यांकन करता है। एक पॉलिसी परिभाषा को एक बाइंडिंग के साथ जोड़ा जाता है जो संसाधनों का चयन करती है और प्रवर्तन (enforcement) कार्रवाई को परिभाषित करती है। यह क्लस्टर-नेटिव वैलिडेशन पाथ प्रदान करता है, लेकिन खराब तरीके से स्कोप की गई या अनुपलब्ध पॉलिसी वैध रिकवरी ऑपरेशन्स को अस्वीकार कर सकती है।
मान लें कि प्रोडक्शन नेमस्पेस लेबल किए गए हैं, इमेज प्रोवेनेंस एडमिशन फ़ील्ड के रूप में उपलब्ध है, और प्लेटफ़ॉर्म इंजीनियर पॉलिसी के ओनर हैं। डिज़ाइन को सख्त सुरक्षा नियमों को चेतावनियों से अलग करना चाहिए, ड्राई रन का समर्थन करना चाहिए, और एक ऑडिटेड इमरजेंसी पाथ को बनाए रखना चाहिए।
इंटरव्यूअर्स क्या मूल्यांकन करते हैं
इंटरव्यूअर्स पॉलिसी परिभाषा और बाइंडिंग के बीच अलगाव, स्पष्ट विफलता व्यवहार (explicit failure behavior), संकीर्ण संसाधन मिलान (narrow resource matching), और एक परीक्षण योग्य छूट मॉडल की तलाश करते हैं। मजबूत उत्तर CEL टाइप चेकिंग, वर्जन किए गए रोलआउट, ऑडिट मेट्रिक्स, और पॉलिसी इंजन या संदर्भित डेटा अनुपलब्ध होने पर क्या होता है, इस पर चर्चा करते हैं।
एक सामान्य उत्तर केवल एक एक्सप्रेशन लिखता है जो खराब YAML को अस्वीकार करता है। एक मजबूत उत्तर स्कोप, एक्शन लेवल्स, अनुकूलता, ऑब्जर्वेबिलिटी और रोलबैक की व्याख्या करता है।
पहले स्पष्ट करने योग्य प्रश्न
- कौन से API ग्रुप्स, वर्जन्स, नेमस्पेस और ऑपरेशन्स स्कोप में हैं?
- क्या नियम इमेज आइडेंटिटी, डाइजेस्ट पिनिंग, होस्ट एक्सेस, या इन सभी के बारे में है?
- क्या किसी उल्लंघन पर पायलट के दौरान डिनाय (deny), चेतावनी (warn), या केवल ऑडिट (audit) किया जाना चाहिए?
- किन कंट्रोलर्स या सिस्टम नेमस्पेस को छूट की आवश्यकता है, और उन्हें कौन मंजूरी देता है?
- यदि कोई पॉलिसी किसी इंसिडेंट फिक्स को ब्लॉक करती है तो रिकवरी पाथ क्या है?
यदि नियम बाहरी स्थिति (external state) पर निर्भर करता है जिसे CEL विश्वसनीय रूप से एक्सेस नहीं कर सकता है, तो पॉलिसी को स्थानीय रखें और समृद्ध जांचों के लिए एक अलग कंट्रोलर का उपयोग करें। यदि छूटें व्यापक हैं, तो पॉलिसी गलत आत्मविश्वास प्रदान कर सकती है।
30-सेकंड का उत्तर
"मैं छोटे, टाइप्ड CEL नियम परिभाषित करूँगा और उन्हें केवल प्रोडक्शन वर्कलोड्स और प्रासंगिक ऑपरेशन्स से बाइंड करूँगा। मैं ऑडिट या वार्निंग मोड में शुरुआत करूँगा, ओनर के आधार पर उल्लंघनों को मापूँगा, और फिर एक समय में एक नियम लागू करूँगा। छूटें संकीर्ण और ऑडिट की गई होंगी, जिसमें एक परीक्षण किया गया इमरजेंसी पाथ होगा। मैं एडमिशन लेटेंसी, रिजेक्शन रेट और रिकवरी सफलता की निगरानी करूँगा, और यदि पॉलिसी का व्यवहार असुरक्षित है तो बाइंडिंग को रोल बैक कर दूँगा।"
चरण-दर-चरण डिज़ाइन
- इनवेरिएंट (invariant) को परिभाषित करें। स्वीकृत इमेज रजिस्ट्री, डाइजेस्ट आवश्यकताओं और होस्ट विशेषाधिकारों के लिए अलग-अलग नियम लिखें। ऐसे एकल एक्सप्रेशन से बचें जिसका परीक्षण करना या समझाना कठिन हो।
- टाइप-चेक करें और CEL का परीक्षण करें। लक्षित संसाधन स्कीमा के विरुद्ध एक्सप्रेशन्स को मान्य करें, जिसमें अनुपलब्ध फ़ील्ड, सूचियाँ, अपडेट और डिलीट ऑपरेशन्स शामिल हैं। पॉलिसी समीक्षा वर्कफ़्लो में फिक्सचर्स बनाए रखें।
- बाइंडिंग के साथ स्कोप करें। केवल उन प्रोडक्शन नेमस्पेस, वर्कलोड प्रकारों और ऑपरेशन्स का मिलान करें जिन्हें सुरक्षा की आवश्यकता है। अलग-अलग बाइंडिंग्स टीमों को स्वतंत्र रूप से नियमों को अपनाने की अनुमति देती हैं।
- प्रवर्तन (Enforcement) चुनें। ऑडिट या चेतावनी से शुरू करें, ओनर्स द्वारा उल्लंघनों को सुधारने के बाद डिनाय (deny) में प्रमोट करें, और परिवर्तन इतिहास में कार्रवाई रिकॉर्ड करें।
- छूटों को डिज़ाइन करें। केवल नामित सिस्टम पहचानों या नेमस्पेस को छूट दें, एक समाप्ति तिथि या अनुमोदन रिकॉर्ड की आवश्यकता रखें, और छूट का उपयोग होने पर अलर्ट करें।
- सुरक्षित रूप से रोल बैक करें। पॉलिसी परिभाषाओं को वर्जन में रखें, इतिहास को हटाने के बजाय बाइंडिंग को अक्षम (disable) करें, और सत्यापित करें कि आपातकालीन Deployments प्रलेखित पाथ के तहत आगे बढ़ सकते हैं।
विकल्पों में बाहरी डेटा के लिए एक वैलिडेटिंग वेबहुक या नॉर्मलाइज़ेशन के लिए म्यूटेशन प्लस वैलिडेशन शामिल हैं। नियतात्मक (deterministic), स्थानीय इनवेरिएंट्स के लिए बिल्ट-इन पॉलिसी का उपयोग करें जिन्हें API सर्वर के करीब लागू किया जाना चाहिए।
उदाहरण उत्तर
"मैं तीन पॉलिसियाँ बनाऊँगा: रजिस्ट्री अलाउ-लिस्ट, डाइजेस्ट आवश्यक, और प्रोडक्शन Deployments के लिए hostNetwork निषिद्ध। प्रत्येक बाइंडिंग केवल लेबल किए गए प्रोडक्शन नेमस्पेस का चयन करेगी। पायलट एक सप्ताह के लिए ऑडिट मोड में चलता है; ओनर्स को उल्लंघन रिपोर्ट प्राप्त होती हैं, और हम डिनाय को सक्षम करने से पहले गलत सकारात्मकताओं (false positives) को ठीक करते हैं। प्लेटफ़ॉर्म और ब्रेक-ग्लास पहचान ही एकमात्र छूट हैं, समाप्ति और ऑडिट इवेंट्स के साथ। हम एडमिशन लेटेंसी और अस्वीकृत रिकवरी परिवर्तनों पर अलर्ट करते हैं, और यदि कोई इंसिडेंट किसी असुरक्षित नियम को उजागर करता है तो बाइंडिंग को अक्षम करके रोलबैक करते हैं।"
सामान्य गलतियाँ
- गलती: प्रत्येक नेमस्पेस और ऑपरेशन का मिलान करना → यह क्यों विफल होता है: सिस्टम कंट्रोलर्स और रिकवरी पाथ ब्लॉक हो जाते हैं → समाधान: बाइंडिंग्स को संकीर्ण रूप से स्कोप करें।
- गलती: चेतावनियों को प्रवर्तन के रूप में मानना → यह क्यों विफल होता है: उपयोगकर्ता मान लेते हैं कि सुरक्षा की गारंटी है → समाधान: एक्शन लेवल और प्रमोशन मानदंडों का संचार करें।
- गलती: अनुपलब्ध फ़ील्ड्स पर अनटाइप्ड CEL का उपयोग करना → यह क्यों विफल होता है: अपडेट और पुराने API वर्जन्स अलग तरह से व्यवहार करते हैं → समाधान: अनुपस्थित-फ़ील्ड मामलों को टाइप-चेक और टेस्ट करें।
- गलती: छूटों को स्थायी बनाना → यह क्यों विफल होता है: बायपास ही वास्तविक पॉलिसी बन जाते हैं → समाधान: समाप्ति, ओनर और ऑडिट की आवश्यकता रखें।
फॉलो-अप प्रश्न और उत्तर
क्या होगा यदि किसी पॉलिसी एक्सप्रेशन में सिंटैक्स त्रुटि हो?
Kubernetes पॉलिसी परिभाषा को मान्य करता है और अमान्य एक्सप्रेशन को स्वीकार करने के बजाय त्रुटि की रिपोर्ट करता है। फिर भी इसे समीक्षा फिक्सचर्स के माध्यम से चलाएं और व्यवहार की पुष्टि होने तक बाइंडिंग को ऑडिट मोड में रखें।
आप ऐसे नियम को कैसे संभालते हैं जिसे बाहरी भेद्यता डेटाबेस (vulnerability database) की आवश्यकता होती है?
यह दिखावा न करें कि CEL मनमाने बाहरी स्थिति को फ़ेच कर सकता है। एक कंट्रोलर या वेबहुक का उपयोग करें जो फ्रेशनेस, टाइमआउट और फेलियर सेमेन्टिक्स को संभालता है, जबकि बिल्ट-इन पॉलिसी में स्थानीय इनवेरिएंट्स को बनाए रखता है।
जब कोई डिनाय नियम किसी फिक्स को ब्लॉक कर देता है तो ऑन-कॉल इंजीनियर कैसे रिकवर कर सकता है?
समाप्ति के साथ एक संकीर्ण, ऑडिटेड ब्रेक-ग्लास पहचान या नेमस्पेस प्रदान करें, अनुमोदन का दस्तावेजीकरण करें, और उपयोग पर अलर्ट करें। प्रवर्तन से पहले पाथ का परीक्षण करें।
आप पॉलिसी को कब हटाएंगे?
जब गलत सकारात्मकताएं (false positives) अधिक बनी रहें, एडमिशन लेटेंसी API सर्वर के लिए खतरा बने, या इनवेरिएंट एक मजबूत नियंत्रण में स्थानांतरित हो गया हो, तब बाइंडिंग को हटाएं या अक्षम करें। निर्णय के लिए इतिहास और मेट्रिक्स को सुरक्षित रखें।