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. सञ्जाल मार्ग तयार भएपछि निजी पहुँच सक्षम गर्नुहोस्

झन्डा खोल्नु सजिलो आधा हो। टनेललाई एन्डपोइन्टका निजी ठेगानासम्म मार्ग चाहिन्छ, र क्लस्टर सुरक्षा समूहलाई VPN ले वास्तवमा प्रस्तुत गर्ने स्रोतबाट TCP 443 चाहिन्छ। 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 पुग्न मात्र सीमा खुकुलो पार्ने अनुमति पाउनु हुँदैन। अन्तिम अवस्था, मिति र पुनःप्राप्ति मार्ग रनबुकमा लेख्नुहोस्, त्यसपछि पुनःप्राप्ति मार्ग एकचोटि परीक्षण गर्नुहोस् जब यो अझै सजिलो छ।