प्रांप्ट और संदर्भ
मल्टी-टेनेंट Kubernetes क्लस्टर में, एक आंतरिक API को कॉल करने के लिए एक सेवा को mTLS का उपयोग करना चाहिए। एप्लिकेशन फ़ाइलों को पढ़ सकता है, लेकिन उसे Kubernetes API को कॉल नहीं करना चाहिए या अपनी इमेज में लंबे समय तक रहने वाली निजी कुंजी (private key) नहीं रखनी चाहिए। प्रमाणपत्रों के अनुरोध, हस्ताक्षर, प्रोजेक्शन, रोटेशन, निरसन (revocation), और ऑडिटिंग के लिए पूर्ण PodCertificateRequest पथ डिज़ाइन करें।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
- क्या आप PodCertificateRequest, पारंपरिक CertificateSigningRequest, और साइनर की जिम्मेदारियों को अलग करते हैं।
- क्या आप समझा सकते हैं कि kubelet-प्रोजेक्टेड वॉल्यूम कुंजियों, प्रमाणपत्रों और ट्रस्ट रूट्स को कैसे अलग करते हैं।
- क्या आप साइनर प्राधिकरण (signer authorization), टेनेंट सीमाओं, रोटेशन विंडो, Pod विलोपन, और नोड कॉम्प्रोमाइज को संभालते हैं।
- क्या आप पहचानते हैं कि PodCertificateRequest v1.35 में बीटा है और डिफ़ॉल्ट रूप से अक्षम है, और v1.36 में इसे स्पष्ट रूप से सक्षम करने की आवश्यकता है।
पूछने योग्य स्पष्टीकरण प्रश्न
- क्या प्रमाणपत्र क्लाइंट प्रमाणीकरण, सर्वर प्रमाणीकरण या दोनों (mutual mTLS) के लिए है?
- कौन से SANs, लाइफ़टाइम, ट्रस्ट रूट्स और निरसन सिमेंटिक्स आवश्यक हैं?
- क्या क्लस्टर संस्करण, feature gate, रनटाइम कॉन्फ़िगरेशन और kubelet Pod प्रमाणपत्र प्रोजेक्शन का समर्थन करते हैं?
- क्या एप्लिकेशन प्रमाणपत्र समाप्त होने से पहले फ़ाइलों को फिर से खोल सकता है या निर्देशिका परिवर्तनों को देख (watch) सकता है?
30-सेकंड उत्तर रूपरेखा
मैं kubelet को Pod की ओर से एक प्रमाणपत्र का अनुरोध करने दूंगा। साइनर केवल एक अधिकृत साइनर और सीमित पहचान फ़ील्ड स्वीकार करेगा, फिर केवल-पढ़ने योग्य (read-only) प्रोजेक्टेड वॉल्यूम के माध्यम से कुंजी, प्रमाणपत्र और ट्रस्ट रूट वितरित करेगा। एप्लिकेशन API को कॉल करने के बजाय फ़ाइलों को पढ़ेगा और रोटेशन के दौरान उन्हें फिर से लोड करेगा। अनुरोध, जारी करना, प्रोजेक्शन और रीफ्रेश ऑडिट करने योग्य होंगे; विफलता की स्थिति में अभी भी वैध पुराना प्रमाणपत्र बरकरार रहेगा या नए कनेक्शन ब्लॉक हो जाएंगे। चूँकि PodCertificateRequest v1.35 में बीटा है और डिफ़ॉल्ट रूप से अक्षम है, और v1.36 में feature gate और रनटाइम कॉन्फ़िगरेशन की आवश्यकता होती है, इसलिए मैं क्षमता पहचान और नोड-पूल कैनरी के साथ शुरुआत करूंगा।
चरण-दर-चरण गहन विश्लेषण
1. पहचान और प्राधिकरण सीमाओं को परिभाषित करें
Pod एक उद्देश्य और लक्षित साइनर घोषित करता है, लेकिन मनमाना CA नहीं चुन सकता है। एडमिशन नीति namespace, service account, Pod लेबल्स और अनुमत साइनर्स को बांधती है; साइनर अनुरोध मूल, SAN टेम्प्लेट और कुंजी एल्गोरिदम को मान्य करता है, और क्रॉस-टेनेंट विषयों को अस्वीकार करता है। API पहुंच kubelet और नियंत्रण-प्लेन घटकों के पास रहती है जबकि एप्लिकेशन को केवल फ़ाइल-पढ़ने की पहुंच प्राप्त होती है।
2. अनुरोध और प्रोजेक्शन पथ डिज़ाइन करें
Kubelet Pod अनुरोध बनाता है और हस्ताक्षरित परिणाम प्राप्त करता है। निजी कुंजी नोड पर उत्पन्न होती है ताकि यह कभी भी इमेज या व्यावसायिक API में प्रवेश न करे। प्रमाणपत्र, कुंजी और ट्रस्ट बंडल को न्यूनतम-विशेषाधिकार अनुमतियों के साथ अलग-अलग माउंट किया जाता है। प्रोजेक्शन परमाणु प्रतिस्थापन (atomic replacement) का उपयोग करता है ताकि एप्लिकेशन आंशिक रूप से लिखी गई फ़ाइल को न देख सके। साइनर का नाम, लाइफ़टाइम और SAN को ऑडिट विशेषताओं के रूप में रिकॉर्ड किया जाता है।
3. रोटेशन, निरसन और विफलता को संभालें
समाप्ति से पहले रीफ्रेश करें और kubelet पुनरारंभ, नेटवर्क हानि, और अस्थायी CA आउटेज को कवर करें। नई श्रृंखला मान्य होने तक पुराने प्रमाणपत्र को रखें; लोड विफलता पर, नए कनेक्शन अस्वीकार करें और एक स्वास्थ्य संकेत (health signal) प्रदर्शित करें। Pod विलोपन, service-account परिवर्तन, या नोड रीसाइक्लिंग के बाद प्रोजेक्शन हटा दें। निरसन CA अनुबंध पर निर्भर करता है, जैसे कि CRL, OCSP, या संक्षिप्त लाइफ़टाइम; Kubernetes प्रत्येक साइनर के लिए एक सार्वभौमिक निरसन व्यवहार प्रदान नहीं करता है।
4. संस्करणों और प्रेक्षणीयता (observability) की योजना बनाएं
तैनाती से पहले v1.35 बीटा डिफ़ॉल्ट-ऑफ स्थिति, v1.36 feature gate और रनटाइम कॉन्फ़िगरेशन, और साइनर-kubelet संगतता मैट्रिक्स को सत्यापित करें। अनुरोध विलंबता, जारी करने की विफलताएं, शेष लाइफ़टाइम, रोटेशन सफलता, अनुमति त्रुटियां और अप्रत्याशित SANs की निगरानी करें। लॉग में अनुरोध UID, namespace, Pod, साइनर और परिणाम होना चाहिए, कभी भी निजी कुंजियाँ या पूर्ण प्रमाणपत्र निकाय नहीं होने चाहिए। कैनरी के दौरान एक अल्पकालिक लीगेसी प्रोजेक्शन पथ और रोलबैक स्विच रखें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं एक Pod प्रमाणपत्र को kubelet द्वारा मध्यस्थता वाले अल्पकालिक पहचान क्रेडेंशियल के रूप में मानूंगा। एडमिशन namespace और service account को एक अनुमत साइनर से बांधता है; साइनर SANs, एल्गोरिदम, लाइफ़टाइम और टेनेंट सीमाओं को मान्य करता है। कुंजी नोड पर उत्पन्न होती है, जबकि प्रमाणपत्र, कुंजी और ट्रस्ट रूट अलग-अलग केवल-पढ़ने योग्य प्रोजेक्टेड फ़ाइलों के रूप में वितरित किए जाते हैं। एप्लिकेशन कभी भी API को कॉल नहीं करता है: यह निर्देशिका को देखता है या प्रति अनुरोध फ़ाइलों को फिर से खोलता है और नई श्रृंखला को मान्य करने के बाद ही परमाणु रूप से स्विच करता है। रोटेशन जल्दी शुरू होता है; एक अस्थायी आउटेज अभी भी वैध पुराने प्रमाणपत्र को बनाए रखता है, जबकि समाप्ति या पहचान परिवर्तन नए कनेक्शन को रोकता है और एक अलर्ट जारी करता है। Pod विलोपन प्रोजेक्शन को हटा देता है, और निरसन संक्षिप्त लाइफ़टाइम या CRL/OCSP के लिए साइनर अनुबंध का पालन करता है। रोलआउट से पहले, मैं v1.35 बीटा डिफ़ॉल्ट-ऑफ स्थिति और v1.36 feature gate और रनटाइम कॉन्फ़िगरेशन को सत्यापित करता हूं, फिर अनुरोध UID, साइनर, विलंबता, विफलता दर और शेष लाइफ़टाइम रिकॉर्ड करते हुए नोड पूल द्वारा कैनरी करता हूं।
सामान्य गलतियाँ
- एप्लिकेशन को एक Kubernetes API टोकन देना जो मनमाने CSR बना सकता है।
- अनुरोधकर्ताओं को किसी भी साइनर, SAN, या क्रॉस-namespace विषय को चुनने की अनुमति देना।
- नोड अनुमतियों की अनदेखी करते हुए निजी कुंजियों को इमेज, ConfigMaps, या लंबे समय तक चलने वाले Secrets में रखना।
- केवल स्टार्टअप पर प्रमाणपत्र पढ़ना और रोटेशन के बाद समाप्त हो चुके फ़ाइल डिस्क्रिप्टर का उपयोग जारी रखना।
- प्रत्येक क्लस्टर संस्करण पर बीटा क्षमता को सक्षम और स्थिर मानना।
- पूर्ण PEM डेटा, निजी कुंजियाँ, या टेनेंट-संवेदनशील ऑडिट फ़ील्ड लॉग करना।
अनुवर्ती प्रश्न और उत्तर
लंबे समय तक रहने वाले Secret का उपयोग क्यों न करें?
एक लंबे समय तक रहने वाला Secret जोखिम विंडो को बढ़ाता है और इसे Pod पहचान और विलोपन से बांधना मुश्किल होता है। kubelet प्रोजेक्शन और रोटेशन वाले अल्पकालिक प्रमाणपत्र क्रेडेंशियल जीवनकाल को कम करते हैं, लेकिन साइनर का निरसन और पुनर्प्राप्ति अनुबंध स्पष्ट रहना चाहिए।
आप किसी कॉम्प्रोमाइज्ड नोड को कैसे सीमित करते हैं?
Pod निर्देशिकाओं और कंटेनर उपयोगकर्ताओं तक नोड पहुंच को प्रतिबंधित करें, संक्षिप्त लाइफ़टाइम और न्यूनतम SANs का उपयोग करें, और उच्च-मूल्य वाली पहचानों को एक पृथक या हार्डवेयर-संरक्षित साइनर के पीछे रखें। ऑडिटिंग और असामान्य-कनेक्शन का पता लगाने से प्रतिक्रिया समय कम हो जाता है।
क्या होगा यदि feature gate अक्षम है?
डिप्लॉयमेंट कंट्रोलर से API संसाधन, रनटाइम कॉन्फ़िगरेशन और kubelet क्षमता का पता लगवाएं। पूर्वापेक्षाएँ अनुपस्थित होने पर वर्कलोड को रोकें या एक ऑडिट किए गए लीगेसी पथ पर स्विच करें; चुपचाप ऐसी फ़ाइलें कभी न बनाएं जो वैध दिखती हैं लेकिन रोटेट नहीं होंगी।