प्रॉम्प्ट और दायरा
यह बैकएंड प्रश्न सर्टिफ़िकेट के लाइफ़साइकिल और सर्विस-टू-सर्विस कम्युनिकेशन सीमाओं का परीक्षण करता है। इसका मुख्य उद्देश्य हर मशीन पर केवल एक नया सर्टिफ़िकेट कॉपी करना नहीं है; इश्युएंन्स, ट्रस्ट अपडेट, कनेक्शन रिप्लेसमेंट और रोलबैक में समय का ओवरलैप होना आवश्यक है।
इंटरव्यूअर क्या मूल्यांकन कर रहा है
- क्या आप लीफ़-सर्टिफ़िकेट, ट्रस्ट-बंडल और रूट-CA माइग्रेशन के बीच अंतर समझते हैं।
- क्या आप लंबे समय तक चलने वाले कनेक्शन्स, कैश, क्लॉक स्क्यू, समवर्ती अपडेट्स और आंशिक नोड विफलता को संभाल सकते हैं।
- क्या आप इमेजेस या एन्वायरनमेंट वेरिएबल्स में प्राइवेट कीज़ रखने के बजाय कम अवधि वाली वर्कलोड आइडेंटिटी का उपयोग करते हैं।
- क्या आप कैनरी, एक्सेप्टेंस चेक, रोलबैक और समाप्ति अलर्ट परिभाषित कर सकते हैं।
पूछने के लिए स्पष्टीकरण वाले प्रश्न
सर्विस डिस्कवरी, छोटे बनाम लंबे कनेक्शन्स, इश्युअर, क्रॉस-क्लस्टर या क्रॉस-डोमेन ट्रस्ट, क्लाइंट्स कीज़ को कैसे लोड करते हैं, अधिकतम रिक्वेस्ट और कनेक्शन लाइफ़टाइम, और क्या दो रूट्स या सर्टिफ़िकेट्स एक साथ रह सकते हैं, इसकी पुष्टि करें। स्पष्ट करें कि टारगेट एक लीफ़ है, एक इंटरमीडिएट CA है, या पूरा ट्रस्ट डोमेन है।
30-सेकंड उत्तर का फ्रेमवर्क
मैं रोटेशन को पहले ट्रस्ट, दूसरे सर्टिफ़िकेट्स और तीसरे क्रमिक कनेक्शन रिप्लेसमेंट में विभाजित करूँगा। पहले प्रत्येक वेरिफ़ायर को पुराने और नए दोनों रूट्स को स्वीकार करने दें, फिर नई चेन पर कम अवधि वाले लीफ़ सर्टिफ़िकेट जारी करें। क्लाइंट्स और प्रॉक्सीज़ नए की-पेयर को एटॉमिक रूप से लोड करते हैं और कनेक्शन्स के ड्रेन होने तक पुरानी सामग्री को बनाए रखते हैं। कैनरी के दौरान मैं हैंडशेक विफलताओं, सर्टिफ़िकेट लाइफ़टाइम, बंडल वर्ज़न और पुनः प्रयासों (retries) की निगरानी करूँगा; किसी भी विसंगति पर मैं इश्युएंन्स रोक दूँगा और पुराने पाथ को रीस्टोर करूँगा, रोलबैक के रूप में सर्टिफ़िकेट वैलिडेशन को कभी डिसेबल नहीं करूँगा।
चरण-दर-चरण समाधान
1. आइडेंटिटी और ट्रस्ट डोमेन स्थापित करें
प्रोडक्शन, स्टेजिंग और अलग-अलग ट्रस्ट डोमेन को अलग करते हुए, प्रत्येक वर्कलोड को एक स्थिर SPIFFE ID या समकक्ष आइडेंटिटी दें। वेरिफ़ायर्स एक ट्रस्ट बंडल रखते हैं, जबकि इश्युअर केवल अधिकृत वर्कलोड अटेस्टेशन के बाद ही हस्ताक्षर करता है। वर्कलोड अपनी प्राइवेट की उत्पन्न करता है और एक्सेस को सीमित करता है; कंट्रोल प्लेन को एप्लिकेशन कॉन्फ़िगरेशन के माध्यम से लंबे समय तक चलने वाली प्राइवेट कीज़ वितरित नहीं करनी चाहिए।
2. पहले एक संगत ट्रस्ट बंडल प्रकाशित करें
रूट या इंटरमीडिएट-CA माइग्रेशन के लिए, एक डुअल-रूट ट्रस्ट बंडल प्रकाशित करें और पुष्टि करें कि वेरिफ़ायर्स ने इसका नया वर्ज़न लोड कर लिया है। पुराने रूट को तुरंत न हटाएं क्योंकि पुराने सर्टिफ़िकेट्स और लंबे समय तक चलने वाले कनेक्शन्स अभी भी मौजूद हैं। नए-सर्टिफ़िकेट का इश्युएंन्स शुरू करने से पहले बंडल वर्ज़न, लोड सफलता और पुराने इंस्टेंसेस को ट्रैक करें।
3. नया सर्टिफ़िकेट जारी और लोड करें
एक वर्कलोड Workload API, एक साइडकार या समकक्ष डायनेमिक इंटरफ़ेस के माध्यम से एक कम अवधि वाली X.509 आइडेंटिटी प्राप्त करता है। एक शुरुआती विंडो के भीतर नवीनीकरण करें और की तथा सर्टिफ़िकेट को एटॉमिक रूप से बदलें: रीडर्स को या तो पुराना पेयर दिखे या नया पेयर, कभी भी दोनों का मिश्रण न दिखे। विफलता पर अंतिम वैध सामग्री को बनाए रखें और पुनः प्रयास करें; समाप्त हो चुके सर्टिफ़िकेट को हमेशा के लिए न बढ़ाएं।
4. कनेक्शन और रिक्वेस्ट सीमाओं को संभालें
नए सर्टिफ़िकेट आम तौर पर नए TLS सेशन्स को प्रभावित करते हैं, जबकि लंबे समय तक चलने वाले कनेक्शन्स पुराना सर्टिफ़िकेट रख सकते हैं। HTTP/2, gRPC, या डेटाबेस पूल्स के लिए एक अधिकतम कनेक्शन आयु (maximum connection age) सेट करें और नए हैंडशेक सफल होने के बाद पुराने कनेक्शन्स को शालीनता से ड्रेन करें। पुनः प्रयासों को आइडेम्पोटेंसी, टाइमआउट और बैकऑफ़ का सम्मान करना चाहिए ताकि रोटेशन एक पुनः प्रयास तूफ़ान (retry storm) में न बदल जाए।
5. कैनरी, रोलबैक और रूट रिमूवल डिज़ाइन करें
पहले एक वर्कलोड पूल और एक ट्रैफ़िक पाथ को वैलिडेट करें, फिर क्षेत्र या सेवा के अनुसार विस्तार करें। रोलबैक नए इश्युएंन्स को रोकता है और पुराने बंडल और कनेक्शन नीति को रीस्टोर करता है; पुराने रूट को केवल तभी हटाएं जब सभी पुराने सर्टिफ़िकेट्स और कनेक्शन्स ड्रेन हो जाएं। यदि नए रूट की प्राइवेट की से समझौता हो जाता है, तो आपातकालीन निरस्तीकरण और अलगाव सामान्य रोटेशन वर्कफ़्लो से स्वतंत्र होना चाहिए।
6. विफलताओं का निरीक्षण और पूर्वाभ्यास करें
सर्टिफ़िकेट-लाइफ़टाइम पर्सेंटाइल, इश्युएंन्स विफलताएं, SVID या बंडल अपडेट विलंब, TLS हैंडशेक त्रुटियां, आइडेंटिटी-और-वर्ज़न समूहीकृत 4xx/5xx, और ड्रेन अवधि की निगरानी करें। टेस्ट आइडेंटिटीज़ के साथ समाप्ति अलर्ट, क्लॉक स्क्यू, कंट्रोल-प्लेन अनुपलब्धता और अपडेट न हो पाने वाले क्षेत्र का पूर्वाभ्यास करें। लॉग केवल आइडेंटिटी, वर्ज़न और परिणाम रिकॉर्ड करते हैं, कभी भी प्राइवेट कीज़ नहीं।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं पहले यह पहचान करूँगा कि क्या यह लीफ़, CA, या ट्रस्ट-डोमेन रोटेशन है, फिर प्रत्येक वर्कलोड को एक स्थिर आइडेंटिटी और कम अवधि का X.509 SVID दूँगा। CA माइग्रेशन के लिए, मैं एक डुअल-रूट ट्रस्ट बंडल प्रकाशित करूँगा और पुष्टि करूँगा कि Workload API या प्रॉक्सी के माध्यम से गतिशील रूप से नए लीफ़ सर्टिफ़िकेट जारी करने से पहले वेरिफ़ायर्स इसे लोड कर लें। कीज़ और सर्टिफ़िकेट्स को एटॉमिक रूप से बदलें और वैध पुरानी सामग्री बनाए रखें; नए कनेक्शन्स नए सर्टिफ़िकेट का उपयोग करते हैं, जबकि HTTP/2 और gRPC कनेक्शन्स एक सीमित अधिकतम आयु पर ड्रेन होते हैं। वर्कलोड पूल और क्षेत्र के अनुसार रोल आउट करें, हैंडशेक त्रुटियों, बंडल वर्ज़न, शेष लाइफ़टाइम और पुनः प्रयास दर पर नज़र रखें। विफलता पर, इश्युएंन्स रोकें और पुराने बंडल और कनेक्शन नीति को रीस्टोर करें; वेरिफिकेशन को कभी डिसेबल न करें। पुराने रूट को केवल पुराने सर्टिफ़िकेट्स और कनेक्शन्स के ड्रेन होने के बाद ही हटाएं। टेस्ट आइडेंटिटीज़ के साथ समाप्ति, क्लॉक स्क्यू और कंट्रोल-प्लेन विफलता का पूर्वाभ्यास करें, और प्राइवेट कीज़ को इमेजेस, एन्वायरनमेंट वेरिएबल्स और लॉग्स से बाहर रखें।
सामान्य गलतियाँ
- नया रूट प्रकाशित करने से पहले पुराने रूट को हटा देना, जिससे पुराने सर्टिफ़िकेट्स का उपयोग करने वाले नोड्स टूट जाते हैं।
- लंबे समय तक चलने वाले कनेक्शन्स, पूल्स और इन-फ़्लाइट रिक्वेस्ट्स को संभाले बिना फ़ाइलों को बदल देना।
- प्राइवेट कीज़ को इमेजेस, एन्वायरनमेंट वेरिएबल्स, या एक साधारण कॉन्फ़िगरेशन स्टोर में बेक करना।
- की और सर्टिफ़िकेट को अलग-अलग स्विच करना और एक बेमेल पेयर बनाना।
- विफलता के दौरान TLS वेरिफिकेशन को डिसेबल करना या समाप्त सर्टिफ़िकेट को हमेशा के लिए बढ़ाना।
- बंडल वर्ज़न, हैंडशेक, या अपडेट-विलंब टेलीमेट्री के बिना केवल अंतिम समय का समाप्ति अलर्ट होना।
फ़ॉलो-अप प्रश्न और उत्तर
बंडल में पहले पुरानी और नई दोनों चेन्स को स्वीकार क्यों करें?
वेरिफ़ायर्स नए रूट को सीखते हैं जबकि पुराने सर्टिफ़िकेट्स काम करना जारी रखते हैं, इसलिए इश्युएंन्स और वैलिडेशन के बीच कभी कोई अंतर नहीं आता है। पुराने रूट को केवल तभी हटाएं जब इसका उपयोग करने वाले सर्टिफ़िकेट्स और कनेक्शन्स ड्रेन हो जाएं।
नवीनीकरण के बाद लंबे समय तक चलने वाले कनेक्शन्स का क्या होता है?
उनकी अधिकतम आयु को सीमित करें, उन्हें शालीनता से ड्रेन करें, और एक नए कनेक्शन द्वारा अपना हैंडशेक पूरा करने के बाद उन्हें बंद करें। पुनः प्रयास करने योग्य अनुरोध अभी भी आइडेम्पोटेंसी और बैकऑफ़ नियमों का पालन करते हैं; सभी क्लाइंट्स को एक साथ पुनः कनेक्ट न करें।
क्या अस्थायी कंट्रोल-प्लेन अनुपलब्धता तुरंत सेवा को रोक देती है?
नहीं। आइडेंटिटीज़ और बंडल्स को तब तक कैश करें जब तक वे वैध रहते हैं, जल्दी नवीनीकरण करें, और शेष लाइफ़टाइम पर अलर्ट करें। अनिश्चितकालीन बाईपास बनने के बजाय कैश की एक स्पष्ट सुरक्षा और अनुपालन सीमा होनी चाहिए।
आप कैसे साबित करते हैं कि कोई भी सेवा अब पुराने रूट पर निर्भर नहीं है?
आइडेंटिटी, सर्टिफ़िकेट चेन और बंडल वर्ज़न द्वारा हैंडशेक और लोड रिकॉर्ड करें, फिर एक अवलोकन विंडो के दौरान पुरानी-चेन के शून्य उपयोग की पुष्टि करें। यह मानने के बजाय कि वे अपडेट हो गए हैं, उन नोड्स को अलग करें या रोलबैक करें जो रिपोर्ट नहीं कर सकते।