सिस्टम डिज़ाइन इंटरव्यू: मैनिफ़ेस्ट-आधारित नियंत्रण के साथ Kubernetes एडमिशन नीतियों को सुरक्षित करें

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

यह प्लेटफ़ॉर्म सुरक्षा इंजीनियरों के लिए एक सिस्टम-डिज़ाइन प्रश्न है। Kubernetes v1.36 मैनिफ़ेस्ट-आधारित एडमिशन नियंत्रण को एक अल्फा फ़ीचर के रूप में पेश करता है। रिक्वेस्ट्स को सर्व करने से पहले नीतियों को API-सर्वर-लोकल डायरेक्टरी से लोड किया जाता है, इसलिए डिज़ाइन को etcd उपलब्ध होने से पहले काम करना चाहिए और इसमें एक फ़ाइल-आधारित रिकवरी पाथ शामिल होना चाहिए।

इंटरव्यूअर क्या मूल्यांकन करता है

बूटस्ट्रैप नीति और API-प्रबंधित नीतियों के बीच अलगाव।
एटॉमिक वैलिडेशन, रोलबैक, और फ़ेल-फ़ास्ट स्टार्टअप व्यवहार।
विशेषाधिकार प्राप्त विलोपन (deletion) से नीति और वेबहुक कॉन्फ़िगरेशन की सुरक्षा।
API-सर्वर इंस्टेंसेस में कॉन्फ़िगरेशन वितरण और ड्रिफ्ट का पता लगाना।
ऑपरेटर एस्केप हैच, ऑडिटेबिलिटी, और विफलता-मोड परीक्षण।

कौन से संसाधन सुरक्षित हैं?

स्पष्ट करें कि क्या बेसलाइन केवल ValidatingAdmissionPolicy ऑब्जेक्ट्स की सुरक्षा करती है या बाइंडिंग्स, वेबहुक और म्यूटेटिंग कॉन्फ़िगरेशन की भी सुरक्षा करती है। मैच नियम और ब्लास्ट रेडियस उस उत्तर के साथ बदलते हैं।

रिकवरी प्राधिकारी (Authority) क्या है?

यदि API अनुपलब्ध है या नीति अपनी मरम्मत को ही ब्लॉक करती है, तो आधिकारिक पाथ API-सर्वर होस्ट या उसकी अपरिवर्तनीय (immutable) कॉन्फ़िगरेशन पाइपलाइन होनी चाहिए। परिभाषित करें कि उस पाथ को कौन बदल सकता है और परिवर्तनों की समीक्षा कैसे की जाती है।

कितने API सर्वर चलते हैं?

प्रत्येक इंस्टेंस अपनी फ़ाइलों को पढ़ता है। एक फ़्लीट को कंटेंट-एड्रेस्ड आर्टिफ़ैक्ट्स, रोलआउट सीक्वेंसिंग, और एक कॉन्फ़िगरेशन हैश मेट्रिक की आवश्यकता होती है; एकल सर्वर एक सरल स्थानीय वॉचर का उपयोग कर सकता है लेकिन फिर भी उसे एटॉमिक प्रतिस्थापन की आवश्यकता होती है।

30-सेकंड उत्तर रूपरेखा

"मैं किसी भी API-प्रबंधित नीति को सक्षम करने से पहले एक छोटी, समीक्षित मैनिफ़ेस्ट नीति स्थापित करूँगा। यह सुरक्षित के रूप में चिह्नित संसाधनों के अपडेट या डिलीट को अस्वीकार करता है, और इसका नाम आरक्षित .static.k8s.io प्रत्यय का उपयोग करता है। प्रत्येक API सर्वर समान संस्करण वाली डायरेक्टरी प्राप्त करता है और अपने कॉन्फ़िगरेशन हैश को प्रदर्शित करता है। फ़ाइल परिवर्तन एटॉमिक रूप से मान्य और स्वैप होते हैं; अमान्य अपडेट अंतिम अच्छे संस्करण को बनाए रखते हैं, जबकि अमान्य स्टार्टअप तेज़ी से फ़ेल (fail fast) होता है। ऑपरेटर होस्ट कॉन्फ़िगरेशन पाथ के माध्यम से रिकवर करते हैं, कभी भी ब्लॉक किए गए API के माध्यम से नहीं।"

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

ट्रस्ट बाउंड्री को बूटस्ट्रैप करें

प्रत्येक API सर्वर पर ManifestBasedAdmissionControlConfig सक्षम करें और मौजूदा एडमिशन कॉन्फ़िगरेशन फ़ाइल के माध्यम से staticManifestsDir को कॉन्फ़िगर करें। मैनिफ़ेस्ट को केवल-पढ़ने योग्य (read-only), अखंडता-जाँच (integrity-checked) आर्टिफ़ैक्ट में संग्रहीत करें। प्रत्येक स्थिर ऑब्जेक्ट नाम का .static.k8s.io में समाप्त होना आवश्यक करें ताकि मेट्रिक्स और ऑडिट रिकॉर्ड फ़ाइल-समर्थित ऑब्जेक्ट्स और API ऑब्जेक्ट्स के बीच अंतर कर सकें।

yaml

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionPolicy
  configuration:
    staticManifestsDir: /etc/kubernetes/admission/static

सुरक्षा नियम लिखें

बूटस्ट्रैप नीति एडमिशन नीतियों, बाइंडिंग्स और वेबहुक कॉन्फ़िगरेशन पर UPDATE और DELETE ऑपरेशनों से मेल खाती है। यह परिवर्तनों को केवल तभी अस्वीकार करता है जब पुराने ऑब्जेक्ट में platform.example.com/protected=true जैसा सुरक्षा लेबल हो। यह बेसलाइन की सुरक्षा करते हुए सामान्य प्रयोगों को संभव बनाए रखता है।

अपडेट को ट्रांज़ैक्शनल बनाएं

API सर्वर परिवर्तित फ़ाइल सेट को मान्य करता है और इसे एटॉमिक रूप से स्वैप करता है। यदि रनटाइम पर वैलिडेशन विफल हो जाता है, तो पिछले अच्छे कॉन्फ़िगरेशन को बनाए रखें और त्रुटि को लॉग करें। स्टार्टअप पर, यदि कोई मैनिफ़ेस्ट अमान्य है, तो रिक्वेस्ट सर्व करने से पहले फ़ेल हो जाएं; बेसलाइन के बिना चुपचाप शुरू होने से ठीक वही बूटस्ट्रैप अंतर पैदा होगा जिसे बंद करने के लिए यह फ़ीचर बनाया गया है।

मल्टी-सर्वर फ़्लीट का संचालन करें

प्रत्येक API सर्वर पर समान कंटेंट-एड्रेस्ड बंडल को रेंडर करें और एक बार में एक इंस्टेंस रोलआउट करें। कॉन्फ़िगरेशन-हैश लेबल और एडमिशन निर्णय मेट्रिक्स की तुलना करें। हैश बेमेल होना ड्रिफ्ट है, कोई हानिरहित संस्करण अंतर नहीं; नीति शब्दार्थ (semantics) बदलने से पहले रोलआउट रोकें और ज्ञात बंडल को पुनर्स्थापित करें।

एक एस्केप हैच बनाए रखें

स्थिर नीति को किसी Service, paramKind, या किसी अन्य API ऑब्जेक्ट पर निर्भर नहीं होना चाहिए। क्लस्टर स्थिति मौजूद होने से पहले वे संदर्भ उपलब्ध नहीं होते हैं। फ़ाइलों को बदलने के लिए होस्ट-स्तरीय ऑडिटेड पाथ रखें, और परीक्षण करें कि किसी विकृत या अत्यधिक व्यापक नीति को बिना किसी API कॉल के वापस रोलबैक किया जा सकता है।

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं स्टैटिक डायरेक्टरी को रूट-ऑफ़-ट्रस्ट मानूँगा, प्रत्येक API सर्वर पर एक हस्ताक्षरित संस्करणित बंडल वितरित करूँगा, और लेबल किए गए एडमिशन संसाधनों में संशोधनों को अस्वीकार करने के लिए एक स्टैटिक नीति का उपयोग करूँगा। .static.k8s.io पर समाप्त होने वाले नाम स्रोत को दृश्यमान बनाते हैं। रनटाइम संपादन एटॉमिक रूप से मान्य और स्वैप होते हैं; स्टार्टअप किसी भी अमान्य बंडल को अस्वीकार करता है। प्रत्येक सर्वर एक कॉन्फ़िगरेशन हैश निर्यात करता है, इसलिए ड्रिफ्ट होने पर रोलआउट रुक जाता है। रिकवरी एक ऑडिटेड होस्ट परिवर्तन है, न कि एक API रिक्वेस्ट, और कैनरी परीक्षण बूटस्ट्रैप, विलोपन प्रयासों, विकृत अपडेट, सर्वर पुनरारंभ और मिश्रित बंडलों को कवर करते हैं।"

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

नीतियों को किसी अन्य API नीति से सुरक्षित करना → API अपने स्वयं के कॉन्फ़िगरेशन की रक्षा नहीं कर सकता → सुरक्षा को स्टैटिक फ़ाइलों में एंकर करें।
एक खराब संपादन को सक्रिय सेट को बदलने की अनुमति देना → एक सिंटैक्स त्रुटि सभी सुरक्षा को हटा सकती है → पूरे सेट को मान्य करें और अंतिम अच्छा संस्करण बनाए रखें।
अमान्य मैनिफ़ेस्ट के साथ शुरुआत करना → सर्वर इच्छित बेसलाइन के बिना चलता है → रिक्वेस्ट सर्व करने से पहले तेज़ी से फ़ेल (fail fast) हों।
यह मान लेना कि API सर्वर फ़ाइलें साझा करते हैं → एक इंस्टेंस एक अलग नीति लागू कर सकता है → बंडल वितरित करें और हैश की तुलना करें।
प्रत्येक ऑपरेटर एस्केप हैच को हटाना → एक नीति बग आउटेज बन जाता है → एक विशेषाधिकार प्राप्त, ऑडिटेड होस्ट रिकवरी पाथ बनाए रखें।

स्कोरिंग रूब्रिक और सेल्फ़-चेक

बूटस्ट्रैप सुरक्षा, नीति मिलान, एटॉमिक अपडेट, फ़्लीट निरंतरता, रिकवरी और परीक्षणों को स्कोर करें। एक मजबूत उत्तर बताता है कि स्टैटिक कॉन्फ़िगरेशन सर्कुलर एडमिशन के बिना API-प्रबंधित संसाधनों की रक्षा क्यों कर सकता है, और डिज़ाइन जानबूझकर ऑपरेटरों को एक गैर-API रिकवरी चैनल कहाँ प्रदान करता है।

फ़ॉलो-अप और विस्तार

क्या होगा यदि रोलआउट के दौरान कोई API सर्वर पुनः प्रारंभ हो जाए?

पुराने बंडल को उपलब्ध रखें, सफल स्टैटिक एडमिशन लोड पर तत्परता (readiness) को आधारित करें, और सर्वर को ट्रैफ़िक में वापस जोड़ने से पहले रिपोर्ट किए गए हैश की तुलना करें।

क्या स्टैटिक नीतियां किसी Service वेबहुक को संदर्भित कर सकती हैं?

नहीं। क्लस्टर स्थिति मौजूद होने से पहले यह फ़ीचर पूरी तरह से आत्मनिर्भर है; केवल-URL वाले वेबहुक या बिना API संसाधन निर्भरता वाली CEL नीति का उपयोग करें, फिर उपलब्धता ट्रेड-ऑफ़ का दस्तावेजीकरण करें।

आप ऐसी नीति का परीक्षण कैसे करते हैं जो अपने स्वयं के विलोपन को रोकती है?

एक संरक्षित परीक्षण ऑब्जेक्ट बनाएं, API के माध्यम से अपडेट और डिलीट का प्रयास करें, इनकार और ऑडिट रिकॉर्ड सत्यापित करें, फिर रिकवरी पाथ के माध्यम से स्टैटिक बंडल को बदलें और पुष्टि करें कि ऑब्जेक्ट प्रबंधनीय हो जाता है।

रोलआउट इनवेरिएंट क्या है?

प्रत्येक सेवारत API सर्वर को समान स्वीकृत बंडल हैश को लागू करना होगा, और कम से कम एक ऑडिटेड रिकवरी पाथ तब भी उपलब्ध रहना चाहिए जब API कॉन्फ़िगरेशन परिवर्तनों को अस्वीकार कर दे।