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'

इन्स्टन्समधून कनेक्शन यशस्वी झाले आणि तुमच्या डेस्कवरून अयशस्वी झाले, तर अनुप्रयोगाचा मार्ग ठीक आहे आणि तुमचा प्रवेश सुधारणे आवश्यक आहे. दोन्हीकडून अयशस्वी झाले, तर ओळखपत्रांऐवजी वरील गट आणि मार्ग तपासण्यांपासून सुरुवात करा. ही एकच तुलना या तिकिटांमुळे होणारा बहुतांश गोंधळ टाळते.