EC2 से निजी RDS: वही VPC, peering या कुछ और?

डेवलपर का लैपटॉप स्टाफ़ VPN के ज़रिए निजी RDS इंस्टेंस तक पहुँचता है, पर EC2 पर चल रहा एप्लिकेशन बिल्कुल कनेक्ट नहीं हो पाता। यह टूटी हुई डिप्लॉयमेंट नहीं है। लैपटॉप के पास एक टनल है जो EC2 इंस्टेंस कभी विरासत में नहीं लेता, और RDS में «निजी» का अर्थ है कि डेटाबेस का कोई सार्वजनिक एंडपॉइंट नहीं है, यह नहीं कि मानव VPN उपयोगकर्ता ही एकमात्र अनुमत कॉलर हैं। एप्लिकेशन को अपना अधिकृत मार्ग, सुरक्षा समूह के साथ अपना संबंध और अपनी डेटाबेस पहचान चाहिए, और इन तीनों को चुनने का क्रम ज़्यादातर डिबगिंग बचाता है। पहले मार्ग तय करें, फिर अनुमतियाँ, और फिर अपने डेस्क से नहीं, डिप्लॉय किए गए वातावरण से सत्यापित करें।

लैपटॉप का VPN एप्लिकेशन का मार्ग नहीं है

स्टाफ़ VPN लोगों के लिए जो भी करता है, वह किसी इंस्टेंस के लिए कुछ नहीं करता, जब तक वह इंस्टेंस स्पष्ट रूप से उसी नेटवर्क मार्ग का हिस्सा न हो। निजी सबनेट में EC2 इंस्टेंस VPC राउटिंग, सुरक्षा समूहों और नेटवर्क ACL के ज़रिए RDS तक पहुँचता है। यह किसी मानव की टनल, सत्र या क्रेडेंशियल विरासत में नहीं लेता, और नहीं लेना चाहिए: बिना निगरानी वाली एप्लिकेशन कनेक्टिविटी और स्टाफ़ की दूरस्थ पहुँच को स्वतंत्र रूप से संचालित होना चाहिए।

यह स्वतंत्रता एक विशेषता है। जब VPN डाउन होता है, एप्लिकेशन काम करता रहता है। जब एप्लिकेशन गलत व्यवहार करता है, किसी की दूरस्थ पहुँच नहीं जाती। दोनों को एक मार्ग में मिलाने वाले डिज़ाइन आमतौर पर किसी घटना के दौरान ही पकड़े जाते हैं, सबसे बुरे संभव क्षण पर।

निर्णय 1: वही VPC, सीधा मार्ग

जब एप्लिकेशन और डेटाबेस एक ही VPC में सीधे राउटिंग के साथ और उनके बीच कोई निरीक्षण मध्यबॉक्स न हो, तो मार्ग सरल होता है और सुरक्षा-समूह संदर्भ उपलब्ध सबसे शक्तिशाली उपकरण है। एप्लिकेशन को उसका अपना समूह दें, फिर पता-सीमा से नहीं बल्कि उसी समूह से डेटाबेस पोर्ट की अनुमति दें:

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

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

फिर अभी जोड़े गए नियम पर रुकने के बजाय मार्ग का बाकी हिस्सा जाँचें। एप्लिकेशन की आउटबाउंड नीति, डेटाबेस से जुड़े समूहों का पूरा सेट, सबनेट राउट तालिकाएँ और कोई भी नेटवर्क ACL—सबको मेल खाना चाहिए। सुरक्षा-समूह के नियम स्टेटफुल होते हैं, जबकि कस्टम नेटवर्क ACL को अनुरोध और वापसी ट्रैफ़िक को अलग नियमों में अनुमति देनी होती है, अल्पकालिक पोर्ट सहित। नया संकीर्ण डेटाबेस नियम पहले से जुड़ी पुरानी व्यापक अनुमति को भी रद्द नहीं करता।

निर्णय 2: दूसरा VPC या दूसरा खाता

अगर एप्लिकेशन दूसरे VPC में है, तो नेटवर्क के मालिक समर्थित निजी इंटरकनेक्ट चुनते हैं: peering, ट्रांज़िट डिज़ाइन या साझा VPC व्यवस्था। तब राउटिंग की दोनों दिशाएँ मौजूद होनी चाहिए, नाम विश्लेषण RDS एंडपॉइंट के लिए काम करना चाहिए, और डेटाबेस नीति जिस स्रोत का मूल्यांकन करती है उसे वास्तव में आने वाले से मेल खाना चाहिए। खाता नाम मेल खाना या साझा बिलिंग संबंध इनमें से कुछ नहीं देता।

सुरक्षा-समूह संदर्भ वह हिस्सा है जो बदलता है। यह कई निजी इंटरकनेक्ट डिज़ाइनों में काम करता है, पर जिस क्षण कोई मध्यबॉक्स स्रोत को फिर से लिखता है या कनेक्शन समाप्त करता है, उसी क्षण काम करना बंद कर देता है, क्योंकि फिर डेटाबेस आपके एप्लिकेशन समूह के बजाय मध्यबॉक्स देखता है। RDS VPC परिदृश्य एक ही VPC के भीतर पहुँच को अन्य व्यवस्थाओं से अलग करते हैं, और यह मानने से पहले कि कोई नियम शैली आगे बढ़ती है, अपनी विशिष्ट टोपोलॉजी उनके सामने जाँचना उचित है।

मौजूद न होने वाले मार्ग को डेटाबेस को सार्वजनिक रूप से सुलभ बनाकर हल न करें। वह अलग मालिक वाला अलग एक्सपोज़र निर्णय है, और आमतौर पर उसे वही सुझाता है जो परिणाम से सबसे दूर है।

निर्णय 3: डेटाबेस कौन-सी पहचान स्वीकार करता है

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

एप्लिकेशन के कॉन्फ़िगरेशन में एक बार की खोज से पकड़े गए पते के बजाय RDS एंडपॉइंट का नाम इस्तेमाल करें। Multi-AZ फेलओवर उस नाम के पीछे का पता बदल देता है, और IP पर पिन किया गया एप्लिकेशन ठीक उसी क्षण विफल होगा जब उसकी सबसे ज़्यादा ज़रूरत हो। त्रुटि गायब करने के लिए इंजन का TLS सत्यापन बंद करने के बजाय उसे चालू रखें, क्योंकि सत्यापन विफलता आपको उस एंडपॉइंट के बारे में कुछ बताती है जहाँ आप पहुँचे।

फिर डेटाबेस खाते को उतना ही दें जितना एप्लिकेशन को चाहिए, उसी स्कीमा में जिसका वह वास्तव में उपयोग करता है। वह काम उबाऊ है, वह ऑडिट-योग्य है, और घटना समीक्षा उसी हिस्से के बारे में पूछेगी।

डिप्लॉय किए गए वातावरण से सत्यापित करें

इंस्टेंस से या उसी समूह, सबनेट और भूमिका के साथ चलने वाले कार्य से परीक्षण करें। चार विफलताएँ लैपटॉप से एक जैसी दिखती हैं और वहाँ से आसानी से अलग पहचानी जाती हैं: ऐसा नाम जो हल न हो, ऐसा कनेक्शन जिसका समय समाप्त हो जाए, TLS सत्यापन विफलता और अस्वीकृत डेटाबेस लॉगिन। हर एक अलग सीमा की ओर इशारा करती है, और यह जानने से पहले कि आपके पास कौन-सी है, डेटाबेस का एक्सपोज़र बदलना अनुमान है।

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

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