प्रॉम्प्ट और संदर्भ
एक क्लस्टर Gateway बाहरी HTTPS स्वीकार करता है और अनुरोधों को एक आंतरिक Service पर अग्रेषित करता है जो केवल TLS स्वीकार करती है। अपस्ट्रीम TLS कॉन्फ़िगर करने, प्रमाणपत्रों और होस्टनामों को सत्यापित करने, और अमान्य नीतियों, क्रॉस-नेमस्पेस संदर्भों और रोलबैक को संभालने के लिए Gateway API BackendTLSPolicy का उपयोग करने का तरीका बताएं।
साक्षात्कारकर्ता क्या परीक्षण कर रहा है
- क्लाइंट TLS समाप्ति को Gateway-से-बैकएंड TLS उत्पत्ति से अलग करना।
- यह समझना कि नीति एक लक्ष्य संदर्भ (target reference) के माध्यम से Service से जुड़ती है और कार्यान्वयन के माध्यम से स्थिति की रिपोर्ट करती है।
- CA, सर्वर नाम, क्लाइंट प्रमाणपत्र और सत्यापन छोड़ने के जोखिम को समझाना।
- क्रॉस-नेमस्पेस प्राधिकरण, अनुकूलता, अवलोकनशीलता (observability), रोलबैक और क्रमिक माइग्रेशन का हिसाब रखना।
पूछने के लिए स्पष्टीकरण प्रश्न
- क्या TLS Gateway पर समाप्त होकर फिर से शुरू होता है, या एंड-टू-एंड पास होता है? बैकएंड प्रमाणपत्र SAN में कौन सा सेवा नाम है?
- कौन सा नेमस्पेस CA, क्लाइंट प्रमाणपत्र और निजी कुंजी का मालिक है, और क्या ReferenceGrant या अन्य प्राधिकरण की आवश्यकता है?
- क्या Gateway कार्यान्वयन वर्तमान BackendTLSPolicy संस्करण और लक्षित Route प्रकार का समर्थन करता है?
- प्रमाणपत्र रोटेशन, अमान्य नीति या बैकएंड TLS आउटेज के दौरान ट्रैफ़िक को कैसे देखा, अलग किया और रोलबैक किया जाएगा?
एक 30-सेकंड का उत्तर
मैं दो TLS चरणों को अलग करूँगा: क्लाइंट से Gateway तक समाप्ति, और Gateway से Service तक अपस्ट्रीम TLS। BackendTLSPolicy Service से जुड़ती है और सत्यापन सामग्री के साथ-साथ वैकल्पिक क्लाइंट पहचान घोषित करती है; कार्यान्वयन को यह रिपोर्ट करना चाहिए कि नीति मान्य है या नहीं। रोलआउट से पहले मैं CA, सर्वर नाम, पोर्ट, क्रॉस-नेमस्पेस प्राधिकरण और कार्यान्वयन समर्थन को सत्यापित करूँगा, प्रमाणपत्र जांच को कभी भी बायपास नहीं करूँगा। मैं एक बैकएंड पर कैनरी परीक्षण करूँगा, नीति स्थिति, हैंडशेक त्रुटियों और समाप्ति की निगरानी करूँगा, और एक प्रतिवर्ती रोलबैक तैयार रखूँगा।
चरण-दर-चरण गहन विश्लेषण
1. TLS सीमा को परिभाषित करें
Gateway API TLS गाइड अपस्ट्रीम TLS कॉन्फ़िगरेशन को Service से जुड़ी BackendTLSPolicy में रखता है। क्लाइंट TLS समाप्ति के बाद, Gateway बैकएंड के लिए एक TLS क्लाइंट के रूप में कार्य करता है; बैकएंड प्रमाणपत्र को कॉन्फ़िगर की गई ट्रस्ट सामग्री के विरुद्ध मान्य होना चाहिए और इसका सर्वर नाम प्रमाणपत्र पहचान से मेल खाना चाहिए। बाहरी श्रोता (listener) प्रमाणपत्र बैकएंड सत्यापन कॉन्फ़िगरेशन नहीं है।
2. अटैचमेंट और सत्यापन सामग्री डिज़ाइन करें
नीति का लक्ष्य संदर्भ एक Service की ओर इशारा करता है। सत्यापन CA प्रमाणपत्र संदर्भों या विनिर्देश द्वारा परिभाषित प्रसिद्ध CA विकल्प का उपयोग कर सकता है। यदि बैकएंड को म्यूचुअल TLS की आवश्यकता है, तो एक क्लाइंट प्रमाणपत्र और कुंजी कॉन्फ़िगर करें और Secret एक्सेस को प्रतिबंधित करें। यह सरलीकृत उदाहरण फ़ील्ड संबंधों पर चर्चा करने के लिए है; कार्यान्वयन के लिए API संस्करण और समर्थित फ़ील्ड सत्यापित करें:
apiVersion: gateway.networking.k8s.io/v1alpha3
kind: BackendTLSPolicy
metadata:
name: payments-upstream-tls
spec:
targetRefs:
- group: ""
kind: Service
name: payments
validation:
hostname: payments.internal.example
wellKnownCACertificates: Systemतैनाती (deployment) से पहले, नीति स्थिति, संदर्भित ऑब्जेक्ट और नियंत्रक के अमान्य होने के कारण का निरीक्षण करें; केवल ऑब्जेक्ट का निर्माण यह साबित नहीं करता कि नीति सक्रिय है।
3. नेमस्पेस और प्रमाणपत्र रोटेशन को संभालें
नीति और लक्षित Service नेमस्पेस सीमा को स्पष्ट रखें। एक क्रॉस-नेमस्पेस संदर्भ के लिए कार्यान्वयन द्वारा समर्थित प्राधिकरण तंत्र की आवश्यकता होती है; Gateway की Service तक पहुँचने की क्षमता उसके Secret को पढ़ने की अनुमति नहीं देती है। ओवरलैप विंडो या दोहरे-CA रणनीति के साथ प्रमाणपत्रों को घुमाएँ (rotate करें), हैंडशेक की सफलता का निरीक्षण करें, फिर पुरानी सामग्री को हटा दें और सत्यापित करें कि कनेक्शन फिर से बने हैं।
4. निरीक्षण करें, कैनरी करें और रोलबैक करें
पहले एक Service या पोर्ट पर कैनरी करें। नीति स्थिति, TLS हैंडशेक विफलताओं, बैकएंड-नाम बेमेल, समाप्ति और कनेक्शन पुनः प्रयासों को रिकॉर्ड करें। जब कोई नीति अमान्य हो जाती है, तो सुरक्षित व्यवहार असुरक्षित कनेक्शन को अस्वीकार करना और एक निदान योग्य घटना उत्सर्जित करना है, न कि चुपचाप प्लेनटेक्स्ट पर डाउनग्रेड करना। रोलबैक अंतिम मान्य नीति या रूट लक्ष्य को पुनर्स्थापित करता है और प्रमाणपत्र और ऑडिट रिकॉर्ड को सुरक्षित रखता है।
आदर्श उत्तर
मैं पहले दो कनेक्शनों को परिभाषित करूँगा: बाहरी TLS Gateway पर समाप्त होता है, जो फिर एक TLS क्लाइंट के रूप में Service से जुड़ता है। BackendTLSPolicy उस Service से जुड़ती है और CA, सर्वर नाम और वैकल्पिक क्लाइंट प्रमाणपत्र घोषित करती है; नियंत्रक स्थिति प्राथमिक संकेत है कि नीति प्रभावी है। मैं Secret और क्रॉस-नेमस्पेस एक्सेस को सीमित करूँगा और कार्यान्वयन के API और Route समर्थन को सत्यापित करूँगा। एक कैनरी Service प्रमाणपत्र SANs, CA ट्रस्ट, रोटेशन, हैंडशेक त्रुटियों और कनेक्शन पुनर्निर्माण का परीक्षण करेगी। मैं अक्षम सत्यापन को कभी भी समाधान नहीं मानूँगा। अमान्य नीति या प्रमाणपत्र विफलताओं को असुरक्षित ट्रैफ़िक को ब्लॉक करना चाहिए, अलर्ट करना चाहिए और रोलबैक योजना का पालन करना चाहिए।
सामान्य गलतियाँ
- केवल क्लाइंट-टू-Gateway प्रमाणपत्र कॉन्फ़िगर करना और अपस्ट्रीम TLS उत्पत्ति को भूल जाना।
targetRefको गलत ऑब्जेक्ट पर इंगित करना या यह मान लेना कि प्रत्येक नियंत्रक समान API संस्करण का समर्थन करता है।- बैकएंड प्रमाणपत्र के सर्वर नाम को सत्यापित किए बिना CA पर भरोसा करना।
- सत्यापन छोड़कर या प्लेनटेक्स्ट फ़ॉलबैक के साथ CA, SAN या रोटेशन की समस्याओं को छुपाना।
- प्राधिकरण और ऑडिट सीमा के बिना क्रॉस-नेमस्पेस Secret पढ़ने की अनुमति देना।
- स्थिति, हैंडशेक मेट्रिक्स और नियंत्रक घटनाओं की अनदेखी करते हुए सफल संसाधन निर्माण को प्रमाण मानना।
अनुवर्ती प्रश्न और उत्तर
BackendTLSPolicy क्लाइंट TLS समाप्ति से कैसे संबंधित है?
क्लाइंट TLS समाप्ति ब्राउज़र या कॉलर से Gateway चरण की सुरक्षा करती है; BackendTLSPolicy Gateway से Service चरण की सुरक्षा करती है। वे विभिन्न प्रमाणपत्रों और ट्रस्ट डोमेन का उपयोग कर सकते हैं, इसलिए पहचान और रोटेशन को अलग से सत्यापित किया जाना चाहिए।
क्या होगा यदि बैकएंड प्रमाणपत्र का नाम मेल नहीं खाता है?
Gateway द्वारा उपयोग किए जाने वाले सर्वर नाम के लिए बैकएंड प्रमाणपत्र जारी करें, या नीति के होस्टनाम को प्रमाणपत्र SAN से मेल कराएं। नाम सत्यापन अक्षम न करें; DNS, SNI, Service नामकरण और प्रमाणपत्र श्रृंखला का निरीक्षण करें।
आप किसी अमान्य नीति को कैसे रिलीज़ करते हैं?
अमान्य स्थिति को एक अलर्ट और रिलीज़ गेट से जोड़ें, कैनरी के विस्तार को रोकें, और संदर्भों, CA सामग्री, Secret अनुमतियों और कार्यान्वयन समर्थन का निरीक्षण करें। स्थिति मान्य होने और हैंडशेक पास होने के बाद ही जारी रखें; आपातकालीन रोलबैक अंतिम मान्य नीति पर वापस लौटता है।