1. परिदृश्य, लक्ष्य और गैर-लक्ष्य
एक इंफ्रास्ट्रक्चर टीम एक साझा Gateway का संचालन करती है जबकि एप्लिकेशन टीमें अपने स्वयं के नेमस्पेस में सेवाओं को तैनात करती हैं। एक भुगतान सेवा की आवश्यकता है कि Gateway कभी भी प्लेनटेक्स्ट न देखे, एक आंतरिक प्रबंधन सेवा को एज पर क्लाइंट-प्रमाणपत्र सत्यापन की आवश्यकता है, और ऑडिटर्स को रूट परिवर्तनों और हैंडशेक विफलताओं को रिकॉर्ड करने की आवश्यकता है। टीमों को स्वतंत्र रूप से रूट प्रकाशित करने चाहिए जबकि प्रमाणपत्र, बैकएंड और लिसनर अनुमतियाँ सीमित रहनी चाहिए।
पहले गैर-लक्ष्य बताएं: Gateway API संसाधन केवल इरादा (intent) व्यक्त करते हैं। ठोस TLS कार्यान्वयन, लोड-बैलेंसिंग व्यवहार और प्रमाणपत्र भंडारण GatewayClass नियंत्रक के गुण बने रहते हैं। इसलिए डिज़ाइन को एक नियंत्रक क्षमता मैट्रिक्स और अनुकूलता जांच की आवश्यकता होती है; एक कार्यान्वयन के व्यवहार को API गारंटी के रूप में नहीं माना जा सकता है।
2. Gateway API 1.5 क्षमताओं का विश्लेषण करें
Gateway API 1.5 TLSRoute, फ़्रंटएंड क्लाइंट-प्रमाणपत्र सत्यापन और संबंधित बैकएंड TLS क्षमताओं को स्थिर समर्थन की ओर ले जाता है, और ReferenceGrant को v1 में पदोन्नत करता है। TLSRoute TLS हैंडशेक के SNI से एक होस्टनाम का मिलान करता है और कनेक्शन को बैकएंड पर अग्रेषित करता है; एक लिसनर Passthrough या Terminate का उपयोग कर सकता है।
Passthrough में, Gateway एन्क्रिप्टेड बाइट्स को प्रॉक्सी करता है और बैकएंड प्रमाणपत्र और हैंडशेक का स्वामित्व रखता है। Terminate में, TLS Gateway पर समाप्त होता है और डिक्रिप्टेड TCP बैकएंड को भेजा जाता है। कुंजी स्वामित्व, डेटा दृश्यता और नीति निष्पादन बिंदु भिन्न होते हैं, इसलिए अकेले प्रदर्शन के आधार पर उनके बीच निर्णय नहीं लिया जा सकता है।
3. संसाधन और स्वामित्व डिज़ाइन करें
प्लेटफ़ॉर्म टीम Gateway और लिसनर्स बनाती है; एप्लिकेशन टीमें नामित लिसनर्स से बंधे हुए TLSRoute ऑब्जेक्ट बनाती हैं। एक रूट को पूरे Gateway पर दावा करने की अनुमति देने के बजाय एक स्पष्ट लिसनर से रूट को बांधने के लिए parentRefs.sectionName का उपयोग करें। होस्टनाम, पोर्ट, प्रोटोकॉल और प्रमाणपत्र संदर्भ समीक्षा के लिए नीति इनपुट हैं।
यह संसाधन युग्म passthrough इरादे को व्यक्त करता है:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: shared-edge
namespace: infra
spec:
gatewayClassName: example-gateway-class
listeners:
- name: tls-passthrough
protocol: TLS
port: 8443
tls:
mode: Passthrough
---
apiVersion: gateway.networking.k8s.io/v1
kind: TLSRoute
metadata:
name: payments
namespace: payments
spec:
parentRefs:
- name: shared-edge
namespace: infra
sectionName: tls-passthrough
hostnames: ["pay.example.com"]
rules:
- backendRefs:
- name: payments
port: 8443क्रॉस-नेमस्पेस संदर्भों को नियंत्रक के प्राधिकरण तंत्र को पास करना होगा और ReferenceGrant या किसी समकक्ष नीति द्वारा स्पष्ट रूप से अनुमति दी जानी चाहिए। डिफ़ॉल्ट दृश्यता पर निर्भर न रहें।
4. Passthrough और Terminate के बीच चयन करें
Passthrough का अर्थ है कि Gateway कोई निजी कुंजी नहीं रखता है और कोई एप्लिकेशन प्रोटोकॉल नहीं देखता है। यह सख्त एंड-टू-एंड एन्क्रिप्शन, डायरेक्ट बैकएंड म्यूचुअल TLS, या एन्क्रिप्टेड TCP आवश्यकताओं के लिए उपयुक्त है। ट्रेड-ऑफ़ यह है कि Gateway HTTP सामग्री पर रूट नहीं कर सकता, एक समान एप्लिकेशन-लेयर सीमा लागू नहीं कर सकता, या एज पर क्लाइंट प्रमाणपत्रों को सत्यापित नहीं कर सकता; बैकएंड हैंडशेक और प्रमाणपत्र-रोटेशन का काम संभालते हैं।
Terminate प्रमाणपत्र प्रबंधन को केंद्रीकृत करता है और एज क्लाइंट-प्रमाणपत्र सत्यापन, सुसंगत रूटिंग और सुसंगत ऑब्ज़र्वेबिलिटी को सक्षम बनाता है। ट्रेड-ऑफ़ Gateway पर प्लेनटेक्स्ट दृश्यता है। यदि बैकएंड हॉप को एन्क्रिप्टेड रहना चाहिए, तो बैकएंड TLS को भी कॉन्फ़िगर करें; निजी-कुंजी का जोखिम और नियंत्रक का विफलता डोमेन भी बढ़ जाता है।
एक साक्षात्कार-गुणवत्ता वाला डिज़ाइन स्तरित होता है: अत्यधिक संवेदनशील भुगतान कनेक्शन को डिफ़ॉल्ट रूप से passthrough पर सेट करें, जबकि उन प्रबंधन सेवाओं को terminate करें जिन्हें केंद्रीकृत पहचान और नीति की आवश्यकता होती है, फिर दूसरे हॉप को बैकएंड TLS से सुरक्षित करें।
5. फ़्रंटएंड mTLS और ट्रस्ट एंकर
फ़्रंटएंड mTLS क्लाइंट-टू-Gateway कनेक्शन को सत्यापित करता है। Gateway कॉन्फ़िगर किए गए CA बंडलों के विरुद्ध क्लाइंट प्रमाणपत्र की जांच करता है; सख्त मोड (strict mode) केवल एक सत्यापित क्लाइंट को स्वीकार करता है। एक असुरक्षित फ़ॉलबैक अनुपलब्ध या अमान्य प्रमाणपत्र को बैकएंड तक पहुंचने की अनुमति दे सकता है, इसलिए इसे नेटवर्क नीति और ऑडिट अलर्ट के साथ संयुक्त रूप से एक स्पष्ट अपवाद होना चाहिए।
टेनेंट या वातावरण के अनुसार ट्रस्ट एंकरों को समूहीकृत करें। नियंत्रित Secret या ConfigMap संदर्भों के माध्यम से CA बंडल वितरित करें। एप्लिकेशन टीमों को प्लेटफ़ॉर्म निजी-कुंजी संदर्भ प्राप्त नहीं होने चाहिए। रोटेशन के दौरान, नया CA प्रकाशित करें, एक दोहरे-विश्वास (dual-trust) विंडो का निरीक्षण करें, पुराने CA को रद्द करें, और सक्रियण समय और दायरे को रिकॉर्ड करें।
6. मल्टी-टेनेंट प्राधिकरण और टकराव
एक साझा Gateway पर लिसनर्स एक प्लेटफ़ॉर्म सीमा हैं। एक एप्लिकेशन को केवल स्वीकृत होस्टनामों और बैकएंड का अनुरोध करना चाहिए। नियंत्रक को ओवरलैपिंग होस्टनाम, अनधिकृत parentRefs, क्रॉस-नेमस्पेस बैकएंड, और नीति से बाहर के पोर्ट या प्रोटोकॉल को अस्वीकार करना चाहिए, और संसाधन status में कारण प्रदर्शित करना चाहिए।
एडमिशन पर ReferenceGrant, Secret संदर्भों और GatewayClass क्षमताओं को मान्य करें। Git में नीति परिवर्तनों की समीक्षा करें; रनटाइम पर नियंत्रक को केवल स्वीकृत संसाधनों से कॉन्फ़िगरेशन प्रस्तुत करना चाहिए। रूट टकराव पर, अंतिम ज्ञात अच्छा कॉन्फ़िगरेशन रखें और अंतिम-लेखक-जीतने वाले (last-writer-wins) व्यवहार को चुपचाप दूसरे टेनेंट को अधिलेखित करने की अनुमति देने के बजाय Accepted=False की रिपोर्ट करें।
7. विफलता, अपग्रेड और ऑब्ज़र्वेबिलिटी
रोलआउट से पहले, सत्यापित करें कि नियंत्रक स्थिर TLSRoute संस्करण, चयनित TLS मोड, क्लाइंट सत्यापन और बैकएंड TLS का समर्थन करता है। Gateway API अपग्रेड के लिए प्रयोगात्मक संसाधनों को स्थिर v1 में स्थानांतरित करने की आवश्यकता हो सकती है; केवल YAML URL को बदलना पर्याप्त नहीं है।
SNI मिलान, लिसनर और रूट conditions, प्रमाणपत्र समाप्ति, क्लाइंट-प्रमाणपत्र विफलता के कारणों, बैकएंड कनेक्शन त्रुटियों, कॉन्फ़िगरेशन प्रसार विलंबता, और प्रति-टेनेंट हैंडशेक और ट्रैफ़िक मेट्रिक्स का निरीक्षण करें। फ़ेलओवर के दौरान ट्रस्ट बंडलों, रूट स्थिति और बैकएंड स्वास्थ्य जांचों को सुसंगत रखें। यदि Gateway अनुपलब्ध है, तो इसे प्लेनटेक्स्ट ट्रैफ़िक से बाईपास करने के बजाय एक स्पष्ट DNS या लोड-बैलेंसर फ़ॉलबैक परिभाषित करें।
8. रूब्रिक और अनुवर्ती प्रश्न
समझाना आवश्यक है
- TLSRoute SNI रूटिंग को Passthrough और Terminate की कुंजी और प्लेनटेक्स्ट सीमाओं से अलग करें।
- फ़्रंटएंड mTLS के लिए CA ट्रस्ट, रोटेशन, विफलता नीति और क्रॉस-नेमस्पेस प्राधिकरण डिज़ाइन करें।
- केवल YAML चिपकाने के बजाय नियंत्रक क्षमता के अंतर, संसाधन conditions, अपग्रेड माइग्रेशन और ऑब्ज़र्वेबिलिटी की व्याख्या करें।
अनुवर्ती प्रश्न
- यदि दो नेमस्पेस समान SNI का दावा करते हैं, तो आप साइलेंट ओवरराइट को कैसे रोकेंगे?
- Gateway द्वारा TLS समाप्त करने के बाद, आप यह कैसे सुनिश्चित करेंगे कि दूसरा हॉप अनुपालन एन्क्रिप्शन बना रहे?
- क्लाइंट-CA रोटेशन के दौरान, पुराने प्रमाणपत्र के अधिकतम जीवनकाल को सीमित करते हुए आप दोहरे प्रमाणपत्रों का समर्थन कैसे करेंगे?
स्कोरिंग गाइड
एक उत्कृष्ट उत्तर संसाधन स्वामित्व, एन्क्रिप्शन सीमाओं, प्राधिकरण और रनटाइम साक्ष्य को जोड़ता है: तय करें कि प्रत्येक कुंजी किसके पास है, status conditions के साथ टकरावों को अस्वीकार करें, और हैंडशेक, प्रमाणपत्र और बैकएंड मेट्रिक्स के साथ नीति को सिद्ध करें।