EKS API کو VPN کے پیچھے رکھیں: کارروائیوں کی ترتیب
نجی endpoint فعال کریں، ثابت کریں کہ kubectl وہاں پہنچا، پھر عوامی endpoint بند کریں۔ ہر مرحلے کے درمیان کمانڈز اور جانچ کے ساتھ مرحلہ وار رن بک۔
اس تبدیلی کا خطرناک ورژن ایک ہی کمانڈ ہے جو endpoint کو پلٹ دیتی ہے اور اسی وقت تمام منتظمین کو باہر بند کر دیتی ہے۔ محفوظ ورژن دونوں راستے کھلے رکھتا ہے، ثابت کرتا ہے کہ نجی راستہ VPN سے کام کرتا ہے، اور اسی کے بعد عوامی endpoint ہٹاتا ہے۔ فرض کریں کہ ایک موجودہ کلسٹر، اس کے VPC میں منظور شدہ ٹنل اور پہلے سے کام کرنے والا kubeconfig موجود ہے؛ کام Kubernetes API تک نجی رسائی ہے، نجی نوڈز نہیں اور نیا اجازت ماڈل نہیں۔ نیچے ہر مرحلے میں ایسی جانچ ہے جہاں آپ محفوظ طریقے سے ناکام ہو سکتے ہیں۔
1. Endpoint کی فہرست بنائیں اور واپسی کا راستہ رکھیں
تبدیل کرنے سے پہلے موجودہ حالت درج کریں، جس میں عوامی 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. نیٹ ورک راستہ تیار ہونے پر نجی رسائی فعال کریں
پرچم روشن کرنا آسان نصف ہے۔ ٹنل کو endpoint کے نجی پتوں تک راستہ چاہیے، اور کلسٹر کے سیکیورٹی گروپ کو اس ماخذ سے TCP 443 چاہیے جو VPN واقعی پیش کرتا ہے۔ Client VPN ایسوسی ایشن، سائٹ ٹو سائٹ گیٹ وے اور peer شدہ 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
اپ ڈیٹ غیر ہم وقت ہے۔ مقررہ سیکنڈ انتظار کر کے فرض کرنے کے بجائے اپ ڈیٹ id سے اس وقت تک پوچھیں جب تک کامیابی کی اطلاع نہ دے۔ ایسا کرتے وقت نوڈز اور کنٹرول پلین کی ٹریفک کو تنہا چھوڑ دیں: کلسٹر کا پورا سیکیورٹی گروپ اپنے لیپ ٹاپ کے لیے ایک قاعدے سے بدلنا ہی کام کرتے ڈیٹا پلین کو دوسرا واقعہ بنانے کا طریقہ ہے۔
EKS endpoint دستاویزات ایک بار مکمل پڑھنے کے قابل ہیں، کیونکہ ان میں کہا گیا ہے کہ صرف نجی رسائی VPC یا منسلک نیٹ ورک سے آ سکتی ہے۔ وہی جملہ اس منتقلی کے ممکن ہونے کی پوری وجہ ہے، اور اگلا مرحلہ ہونے کی وجہ بھی وہی ہے۔
3. ثابت کریں کہ ورک سٹیشن نے نجی راستہ استعمال کیا
دونوں endpoint فعال ہونے پر کامیاب kubectl get ns اس بارے میں کچھ ثابت نہیں کرتا کہ کس نے جواب دیا۔ endpoint کا ہوسٹ نام حل کریں اور دیکھیں کہ ملنے والا پتہ نجی رینج کا ہے یا عوامی۔ اگر آپ کا منسلک نیٹ ورک DNS کے ذریعے نجی منظر نہیں پاتا، تو کمانڈ عوامی endpoint سے کامیاب ہو گی اور آپ جھوٹے ثبوت پر عوامی راستہ ہٹا دیں گے۔ یہی اس منتقلی کے غلط ہونے کا سب سے عام طریقہ ہے، اور یہ بالکل کامیابی جیسا دکھتا ہے۔
nslookup HASH.gr7.REGION.eks.amazonaws.com
kubectl cluster-info
kubectl get ns --request-timeout=10s
ہوسٹ نام اور سرٹیفکیٹ کی تصدیق بالکل ویسی ہی رکھیں جیسی ہیں۔ kubeconfig میں نجی IP ڈالنا اور TLS تصدیق چھوڑ دینا وہ منتقلی نہیں جو آپ نے تبدیلی کے ریکارڈ میں بیان کی، اور endpoint کے گھومنے کے لمحے یہ دوبارہ ناکام ہو گی۔
4. عوامی رسائی جان بوجھ کر ہٹائیں
نجی راستہ ظاہر ہونے اور بحالی کا عمل منظور ہونے کے بعد عوامی endpoint بند کریں۔ یہ پیش نظارہ نہیں بلکہ حقیقی تبدیلی ہے، اس لیے اسے اسی اکاؤنٹ اور ترتیبات پر چلائیں جن کا آپ واقعی ارادہ رکھتے ہیں۔
aws eks update-cluster-config --region REGION --name CLUSTER \
--resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true
صرف نجی موڈ میں عوامی DNS نام VPC کے اندر سے endpoint کے نجی پتوں پر حل ہوتا ہے، اس لیے حل ہونا اور رسائی ایک ہی چیز نہیں رہتے۔ عوامی پتے پر انحصار کرنے والی ہر چیز، بشمول CI رنرز یا کسی دوسرے نیٹ ورک کا لیپ ٹاپ، اب اپنا داخلہ راستہ چاہتی ہے۔
5. نیٹ ورک پالیسی اور شناخت پالیسی الگ رکھیں
عوامی رسائی کی CIDR فہرست صرف عوامی endpoint کو کنٹرول کرتی ہے۔ یہ نجی endpoint کو محدود نہیں کرتی، جسے اس کے بجائے کلسٹر کا سیکیورٹی گروپ اور منسلک نیٹ ورک کی پالیسی محدود کرتی ہے۔ اگر آپ عوامی endpoint رکھتے ہیں تو اس کی اجازت فہرست کو اسی عوامی اخراج سے میل کھانا چاہیے جو آپ کے API کلائنٹس اور نوڈز واقعی استعمال کرتے ہیں؛ VPN پول کا پتہ شاذ و نادر ہی وہ ماخذ ہوتا ہے۔
ان میں سے کوئی بھی IAM یا Kubernetes RBAC کو تبدیل نہیں کرتا۔ endpoint کی ترتیبات انتظامی عمل ہیں، اور عام صارفین کو صرف API تک پہنچنے کے لیے حد نرم کرنے کی اجازت نہیں ملنی چاہیے۔ حتمی حالت، تاریخ اور بحالی کا راستہ رن بک میں لکھیں، پھر بحالی کا راستہ ایک بار اس وقت آزمائیں جب یہ ابھی آسان ہے۔