सिस्टम डिज़ाइन साक्षात्कार: आप Kubernetes Pod सुरक्षा को सुरक्षित रूप से enforce में कैसे माइग्रेट करेंगे?

प्रॉम्प्ट और दायरा

प्लेटफ़ॉर्म टीम को नेमस्पेस को Kubernetes Pod Security Standards के restricted स्तर पर ले जाना होगा। वर्कलोड प्रोडक्शन सेवाओं, शेयर्ड इन्फ्रास्ट्रक्चर और अस्थायी बिल्ड जॉब्स से आते हैं। डिस्कवरी, समाधान (remediation), अपवाद, कटओवर और रोलबैक डिज़ाइन करें।

साक्षात्कारकर्ता क्या जांच रहा है

• enforce, audit, और warn के विभिन्न दुष्प्रभावों को समझना।
• नेमस्पेस, वर्कलोड और अपवादों को एक ही गवर्नेंस सीमा के अंतर्गत लाना।
• सब कुछ तुरंत अस्वीकार करने के बजाय समाधान को आगे बढ़ाने के लिए अवलोकनों (observations) का उपयोग करना।
• पिन किए गए नीति संस्करणों, ऑडिट ट्रेल्स और आपातकालीन रोलबैक पर विचार करना।

स्पष्टीकरण हेतु प्रश्न

1. कौन से Kubernetes संस्करण, टेनेंट सीमाएं और रिलीज़ टूल्स उपयोग में हैं?
2. क्या लक्ष्य baseline है या restricted, और क्या नेमस्पेस विभिन्न स्तरों का उपयोग कर सकते हैं?
3. किन वर्कलोड्स को विशेषाधिकारों (privileges), hostPath, या होस्ट नेटवर्किंग की आवश्यकता है?
4. क्या रोलबैक का अर्थ किसी एक नीति को अस्थायी रूप से कम करना है या ट्रैफ़िक को पुराने क्लस्टर में स्थानांतरित करना है?

एक 30-सेकंड का उत्तर

उल्लंघनों को एकत्र करने और सबमिट करने वालों को कार्रवाई योग्य फ़ीडबैक देने के लिए प्रति-नेमस्पेस audit और warn से शुरुआत करें; पहले ग्लोबल enforce चालू न करें। पिन किए गए नीति संस्करणों के साथ जोखिम और व्यावसायिक प्राथमिकता के क्रम में समाधान करें। प्रत्येक अपवाद के लिए एक ओनर, कारण, समाप्ति अवधि और क्षतिपूर्ति नियंत्रण (compensating control) की आवश्यकता होती है। एक छोटे पायलट के बाद, नेमस्पेस दर नेमस्पेस enforce सक्षम करें और अस्वीकृति व रिलीज़-सफलता दरों पर नज़र रखें। आपातकालीन रोलबैक ऑडिट ट्रेल को बनाए रखते हुए केवल प्रभावित नेमस्पेस नीति को कम करता है।

चरण-दर-चरण डिज़ाइन

1. एक संपत्ति और नीति बेसलाइन स्थापित करें

नेमस्पेस, Pod टेम्पलेट्स, नियंत्रकों और रिलीज़ स्रोतों की सूची बनाएं। प्रोडक्शन, शेयर्ड इन्फ्रास्ट्रक्चर, डेवलपमेंट और अस्थायी जॉब्स को समूहित करें। प्रत्येक समूह के लिए एक लक्षित स्तर और संस्करण चुनें, और अपवादों को रिकॉर्ड करें; एक बिना लेबल वाला नेमस्पेस एक सुरक्षा अंतर (security gap) है, कोई सुरक्षित डिफ़ॉल्ट नहीं।

2. ब्लॉक करने से पहले निरीक्षण करें

उल्लंघनों को रिकॉर्ड करने के लिए audit और क्लाइंट फ़ीडबैक के लिए उसी स्तर पर warn सक्षम करें। एक समाधान कतार में नियम, टीम और इमेज द्वारा घटनाओं को एकत्रित करें। यह वर्तमान ट्रैफ़िक को बाधित किए बिना जोखिम को उजागर करता है।

metadata:
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

3. वर्कलोड का समाधान करें

अनावश्यक विशेषाधिकार, hostNetwork, hostPID, hostPath और लिखने योग्य रूट फ़ाइल सिस्टम को हटाएं। non-root, seccomp, और capability प्रतिबंध जोड़ें। CI में नीति जांच शामिल करें ताकि क्लस्टर द्वारा अस्वीकार किए जाने से पहले एक टेम्पलेट किसी विशिष्ट फ़ील्ड के साथ विफल हो जाए।

4. अपवादों को प्रशासित करें

केवल एक प्रबंधनीय नेमस्पेस या नियंत्रित प्रवेश बिंदु पर ही अपवाद प्रदान करें। प्रभाव, ओनर, समाप्ति अवधि और क्षतिपूर्ति नियंत्रण रिकॉर्ड करें। एक एडमिशन छूट (admission exemption) कोई स्थायी अनुमति-सूची नहीं है; नवीनीकरण के लिए समीक्षा की आवश्यकता होती है, और सिस्टम नेमस्पेस को बिना शर्त पूरी तरह से छूट नहीं दी जानी चाहिए।

5. चरणों में enforce पर कटओवर करें

कम जोखिम वाले नेमस्पेस के लिए पहले enforce सक्षम करें। विस्तार करने से पहले अस्वीकृति, रिलीज़ विफलता, पुनरारंभ (restart) और टेनेंट शिकायत दरों की तुलना करें। नीति संस्करणों को पिन करें; warn और audit में अपग्रेड का पूर्वाभ्यास करें ताकि latest परिवर्तन से अचानक अस्वीकृतियों की लहर पैदा न हो।

6. रोलबैक करें और सत्यापित करें

रिलीज़ नियंत्रकों को पुराने टेम्पलेट्स को रोकने और पुनर्स्थापित करने में सक्षम होना चाहिए। यदि कोई मुख्य सेवा ब्लॉक हो जाती है, तो audit और घटनाओं को बनाए रखते हुए केवल उस नेमस्पेस को अस्थायी रूप से कम करें। नए Pods, Deployment टेम्पलेट्स, रोलिंग अपग्रेड, Jobs, अपवाद समाप्ति और नीति-संस्करण अपग्रेड का परीक्षण करें।

एक आदर्श उच्च-गुणवत्ता वाला उत्तर

मैं नेमस्पेस और वर्कलोड की सूची बनाऊंगा, नीति संस्करणों को पिन करूंगा, फिर audit और उसी स्तर के warn के साथ उल्लंघनों को एकत्र करूंगा। CI सुरक्षा संदर्भों (security contexts) की जल्दी जांच करता है, जबकि अपवादों में ओनर और समाप्ति तिथियां शामिल होती हैं। कम जोखिम वाले नेमस्पेस पहले enforce पर जाते हैं; मैं अस्वीकृति दर, रिलीज़ सफलता और व्यावसायिक त्रुटियों के स्वीकार्य बने रहने के बाद ही विस्तार करता हूं। नीति अपग्रेड का पूर्वाभ्यास warn/audit के साथ किया जाता है। यदि कोई सेवा ब्लॉक हो जाती है, तो मैं क्लस्टर को स्थायी रूप से कमजोर करने के बजाय केवल उसके नेमस्पेस की नीति को रोलबैक करता हूं, ऑडिट ट्रेल को संरक्षित करता हूं, और मूल कारण को ठीक करता हूं।

सामान्य गलतियाँ

• वैश्विक enforce को तुरंत सक्षम करना → कई रिलीज़ एक साथ विफल हो जाती हैं → audit/warn और चरणों का उपयोग करें।
• बिना लेबल वाले नेमस्पेस को सुरक्षित मानना → नीति कवरेज में ब्लाइंड स्पॉट्स होते हैं → उन्हें लेबल करें और सूचीबद्ध करें।
• स्थायी छूट बनाना → जोखिम छिपा रहता है → समाप्ति और समीक्षा अनिवार्य करें।
• केवल क्लस्टर में ही उल्लंघनों का पता लगाना → फ़ीडबैक बहुत देर से मिलता है → जांच को CI और टेम्पलेट समीक्षा में ले जाएं।
• बिना पूर्वाभ्यास के latest का उपयोग करना → एक संस्करण परिवर्तन से अचानक अस्वीकृतियां होती हैं → पिन करें और पहले से निरीक्षण करें।

अनुवर्ती प्रश्न और उत्तर

जब दोनों में से कोई भी ब्लॉक नहीं करता है, तो warn और audit दोनों को क्यों सक्षम करें?

warn सबमिट करने वाले क्लाइंट को तत्काल फ़ीडबैक देता है; audit प्लेटफ़ॉर्म माप के लिए उल्लंघनों को रिकॉर्ड करता है। वे विभिन्न वर्कफ़्लो का समर्थन करते हैं और एक दूसरे की जगह नहीं लेते हैं।

क्या कोई अपवाद Pod तक सीमित होना चाहिए या किसी नेमस्पेस तक?

नियंत्रित प्रवेश बिंदु वाली एक प्रबंधनीय नेमस्पेस सीमा को प्राथमिकता दें। प्रति-Pod अनुमतियों को कॉपी करना और बायपास करना आसान है; सभी अपवादों के लिए अभी भी एक ओनर, समाप्ति और क्षतिपूर्ति नियंत्रण की आवश्यकता होती है।

आप कैसे साबित करेंगे कि उपलब्धता में गिरावट नहीं आई?

प्रत्येक चरण से पहले और बाद में अस्वीकृति, रिलीज़ सफलता, पुनरारंभ, SLOs और टेनेंट त्रुटियों की तुलना करें। लंबे समय तक चलने वाली सेवाओं के साथ-साथ रोलिंग अपग्रेड और अल्पकालिक Jobs को दोबारा चलाकर जांचें।