EKS API को VPN के पीछे रखें: कार्यों का क्रम

इस बदलाव का खतरनाक संस्करण एक ही कमांड है जो एंडपॉइंट को पलट देता है और एक ही समय में हर प्रशासक को बाहर कर देता है। सुरक्षित संस्करण दोनों रास्ते खुले रखता है, सिद्ध करता है कि निजी रास्ता VPN से काम करता है, और उसके बाद ही सार्वजनिक एंडपॉइंट को हटाता है। मान लें कि एक मौजूदा क्लस्टर, उसके VPC में स्वीकृत टनल और पहले से काम करने वाला kubeconfig है; काम Kubernetes API तक निजी पहुँच है, निजी नोड नहीं और नया अनुमति मॉडल नहीं। नीचे के हर चरण में एक जाँच है जहाँ आप सुरक्षित रूप से विफल हो सकते हैं।

1. एंडपॉइंट की सूची बनाएँ और वापसी का रास्ता रखें

बदलने से पहले वर्तमान स्थिति दर्ज करें, जिसमें सार्वजनिक CIDR अनुमत सूची और क्लस्टर सुरक्षा समूह शामिल हैं। जब कुछ काम करना बंद कर देगा तब आप इन्हीं दोनों से तुलना करेंगे, और यदि निजी मार्ग गलत निकला तो अनुमत सूची आपका रोलबैक रास्ता भी है।

aws eks describe-cluster --region REGION --name CLUSTER \
  --query 'cluster.{endpoint:endpoint,public:resourcesVpcConfig.endpointPublicAccess,private:resourcesVpcConfig.endpointPrivateAccess,cidrs:resourcesVpcConfig.publicAccessCidrs}'

REGION और CLUSTER यहाँ प्लेसहोल्डर हैं। ध्यान दें कि निजी फ़्लैग अब क्या दिखाता है, क्योंकि पहले से निजी पहुँच सक्षम होने के साथ बनाया गया क्लस्टर उस क्लस्टर से अलग पहला चरण चाहता है जिसमें यह कभी नहीं था। संक्रमण के दौरान कम से कम एक स्वीकृत प्रशासनिक रास्ता खुला रखें; जो VPN उसी क्लस्टर की पहुँच पर निर्भर है वह रिकवरी रास्ता नहीं है।

2. नेटवर्क रास्ता तैयार होने पर निजी पहुँच सक्षम करें

फ़्लैग चालू करना आसान आधा है। टनल को एंडपॉइंट के निजी पतों तक मार्ग चाहिए, और क्लस्टर सुरक्षा समूह को उस स्रोत से TCP 443 चाहिए जो VPN वास्तव में प्रस्तुत करता है। Client VPN संबद्धता, साइट-टू-साइट गेटवे और पीयर किया गया VPC सभी अलग-अलग स्रोत पते प्रस्तुत कर सकते हैं, इसलिए सामान्य निजी रेंज के बजाय वही मॉडल उपयोग करें जो आपने तैनात किया है।

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=true,endpointPrivateAccess=true

aws eks describe-update --region REGION --name CLUSTER --update-id UPDATE_ID

अपडेट अतुल्यकालिक है। निश्चित सेकंड प्रतीक्षा करके मान लेने के बजाय अपडेट आईडी से तब तक पूछें जब तक वह सफलता की सूचना न दे। ऐसा करते समय नोड और नियंत्रण-तल के ट्रैफ़िक को अकेला छोड़ दें: क्लस्टर के पूरे सुरक्षा समूह को अपने लैपटॉप के लिए एक नियम से बदलना ही काम करते डेटा तल को दूसरी घटना बनाने का तरीका है।

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

3. सिद्ध करें कि वर्कस्टेशन ने निजी रास्ता इस्तेमाल किया

दोनों एंडपॉइंट सक्षम होने पर सफल kubectl get ns इस बात का कुछ सिद्ध नहीं करता कि किसने उत्तर दिया। एंडपॉइंट का होस्टनाम हल करें और जाँचें कि आपको मिला पता निजी रेंज का है या सार्वजनिक। यदि आपका जुड़ा नेटवर्क DNS के माध्यम से निजी दृश्य नहीं पाता, तो कमांड सार्वजनिक एंडपॉइंट से सफल होगा और आप झूठे प्रमाण पर सार्वजनिक रास्ता हटा देंगे। यही इस माइग्रेशन के गलत होने का सबसे आम तरीका है, और यह बिल्कुल सफलता जैसा दिखता है।

nslookup HASH.gr7.REGION.eks.amazonaws.com
kubectl cluster-info
kubectl get ns --request-timeout=10s

होस्टनाम और प्रमाणपत्र सत्यापन बिल्कुल वैसे ही रखें जैसे वे हैं। kubeconfig में निजी IP डालना और TLS सत्यापन छोड़ना वह माइग्रेशन नहीं है जिसे आपने परिवर्तन रिकॉर्ड में वर्णित किया, और एंडपॉइंट के घूमते ही यह फिर विफल होगा।

4. सार्वजनिक पहुँच जानबूझकर हटाएँ

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

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true

केवल-निजी मोड में सार्वजनिक DNS नाम VPC के भीतर से एंडपॉइंट के निजी पतों पर हल होता है, इसलिए रिज़ॉल्यूशन और पहुँच एक ही चीज़ रहना बंद कर देते हैं। सार्वजनिक पते पर निर्भर हर चीज़, जिसमें CI रनर या किसी दूसरे नेटवर्क का लैपटॉप भी है, अब अपना प्रवेश रास्ता चाहती है।

5. नेटवर्क नीति और पहचान नीति अलग रखें

सार्वजनिक पहुँच CIDR सूची केवल सार्वजनिक एंडपॉइंट को नियंत्रित करती है। यह निजी एंडपॉइंट को सीमित नहीं करती, जिसे इसके बजाय क्लस्टर सुरक्षा समूह और जुड़े-नेटवर्क नीति सीमित करती है। यदि आप सार्वजनिक एंडपॉइंट रखते हैं, तो उसकी अनुमत सूची को उस सार्वजनिक इग्रेस से मेल खाना चाहिए जो आपके API क्लाइंट और नोड वास्तव में उपयोग करते हैं; VPN पूल का पता शायद ही वह स्रोत होता है।

इनमें से कोई भी IAM या Kubernetes RBAC नहीं बदलता। एंडपॉइंट सेटिंग्स प्रशासनिक कार्रवाई हैं, और सामान्य उपयोगकर्ताओं को केवल API तक पहुँचने के लिए सीमा ढीली करने की अनुमति नहीं मिलनी चाहिए। अंतिम स्थिति, तिथि और रिकवरी रास्ता रनबुक में लिखें, फिर रिकवरी रास्ता एक बार तब परखें जब वह अभी आसान हो।