কেন kubectl VPN-এ কাজ করে কিন্তু AKS স্কেলিং বন্ধ করে দেয়

আপনি অফিস VPN-এর পাবলিক ঠিকানা AKS API সার্ভারের অনুমোদিত তালিকায় যোগ করেন, আর kubectl কাজ করে। এক সপ্তাহ পরে একটি নোড পুল স্কেল-আপ ব্যর্থ হয়, একটি CI কাজ ক্লাস্টারে পৌঁছাতে পারে না, আর পোর্টাল এমন একটি ত্রুটি দেখায় যেখানে IP রেঞ্জের কথা কিছুই নেই। অনুমোদিত তালিকা কেউ বদলায়নি। আপনি যে নিয়ন্ত্রণ চালু করেছেন তা API সার্ভারের সামনে একটি পাবলিক IP ফিল্টার, এবং এটি জানে না কে কল করছে, শুধু জানে কলটি কোন ঠিকানা থেকে এসেছে। VPN হলো ক্লাস্টারের প্রয়োজনীয় কয়েকটি ঠিকানার মধ্যে একটি, এবং এটিই প্রথমে ভাঙে এমনটা বিরল।

অনুমোদিত তালিকা একটি ঠিকানার সঙ্গে মেলে, ব্যক্তির সঙ্গে নয়

--api-server-authorized-ip-ranges এটি CIDR ব্লক নেয়, ব্যবহারকারী বা গ্রুপ নয়। যখন একজন ডেভেলপারের অনুরোধ VPN সার্ভার ছেড়ে Azure-এর দিকে যায়, API সার্ভারে উৎস ঠিকানা হয় VPN সার্ভারের পাবলিক এগ্রেস। তাই ওই VPN-এর প্রত্যেক ব্যক্তি একটি এন্ট্রি ভাগ করে, আর VPN-এর বাইরের যে কাউকে প্রমাণীকরণের আগেই প্রত্যাখ্যান করা হয়।

এর মানে হলো এন্ট্রিটি আপনার ইচ্ছার চেয়ে বেশি মানুষকে ঢোকার অনুমতি দেয়। VPN অ্যাক্সেস আছে এমন ঠিকাদার, একই কনসেন্ট্রেটরের ব্যক্তিগত ল্যাপটপ এবং একটি হ্যাক হওয়া অ্যাকাউন্ট—সবাই একই ঠিকানা থেকে আসে। ক্লাস্টার অনুমোদন অপরিবর্তিত থাকে, তাই ভূমিকা-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণই ঠিক করে কলকারী কী করতে পারবে, কিন্তু অনুমোদিত তালিকা কোনো পরিচয় নিয়ন্ত্রণ নয় এবং কখনোই তা বলে বর্ণনা করা উচিত নয়।

প্রথমে যা ভাঙে তা সাধারণত kubectl নয়

অনুমোদিত তালিকা API সার্ভারের পাবলিক এন্ডপয়েন্টে প্রযোজ্য, তাই আপনার তালিকাভুক্ত ঠিকানার বাইরে সবকিছু সঙ্গে সঙ্গে কাজ করা বন্ধ করে। স্পষ্ট ক্ষতিগ্রস্তরা হলো VPN রুটহীন দ্বিতীয় অফিস, হোস্টেড পাইপলাইনের একটি CI রানার এবং সংযোগ করতে ভুলে যাওয়া একটি ল্যাপটপ। এদের চেনা সহজ, কারণ একজন মানুষ অপেক্ষা করছে।

কম স্পষ্ট ঘটনাটি হলো Azure বা আপনার নিজের টুলিং চালিত অটোমেশন। প্ল্যাটফর্ম-আরম্ভিত কিছু অপারেশন এমন ঠিকানা থেকে API সার্ভারে পৌঁছায় যা আপনার VPN নয়, আর তালিকা কঠোর করার ঠিক পরে যখন তাদের একটি ব্যর্থ হতে শুরু করে, তখন সময়ই সূত্র। ইন্টারঅ্যাকটিভ অ্যাক্সেস কাজ করছে বলে তালিকাটি সম্পূর্ণ ধরে নেবেন না; আপনার অঞ্চল ও সাবস্ক্রিপশনের জন্য ফিচারটির কী প্রয়োজন তা যাচাই করুন, তারপর ক্লাস্টার নষ্ট বলে সিদ্ধান্তে পৌঁছান।

ব্যর্থতার চিহ্ন সহায়ক। যদি অনুরোধ কখনো প্রমাণীকরণে না পৌঁছায়, তবে এটি ফিল্টার। যদি এটি প্রমাণীকরণ করে তারপর অনুমতি-ত্রুটি পায়, তবে ফিল্টার তার কাজ করেছে এবং সমস্যাটি ভূমিকা-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণে, যা অনুমোদিত তালিকা কখনো স্পর্শ করে না।

পুরো তালিকা একটি কমান্ডে তৈরি করুন

আপডেট প্যারামিটার একটি এন্ট্রি যোগ না করে পুরো তালিকা প্রতিস্থাপন করে, তাই শুধু VPN ঠিকানা বহন করা একটি কমান্ড সেখানে যা ছিল সবকিছু নীরবে ফেলে দেয়। আগে বর্তমান মান পড়ুন, সেটি রাখুন, এবং সম্মিলন পাঠান:

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

এর উপর নির্ভর করার আগে VPN সার্ভারের জন্য একটি সংরক্ষিত পাবলিক IP ব্যবহার করুন। গতিশীল ঠিকানা পুনঃসংযোগে বদলে যায়, আর প্রতিটি পরিবর্তন নীরবে দলকে ক্লাস্টারের বাইরে আটকে রাখে, যতক্ষণ না কেউ এখনো অনুমোদিত কোনো নেটওয়ার্ক থেকে তালিকা হালনাগাদ করে। রিডান্ডেন্সির জন্য দুটি VPN এগ্রেস পয়েন্ট থাকলে দুটিই তালিকাভুক্ত করুন, কারণ ফিল্টারের পছন্দের পথের কোনো ধারণা নেই।

পরিবর্তনটি এমনভাবে সাজান যাতে প্রথম অনুমোদিত প্রচেষ্টাই পরীক্ষা হয়। নতুন তালিকা ঘোষণা করুন, প্রয়োগ করুন এবং সঙ্গে সঙ্গে VPN থেকে সংযোগ করুন; উল্টো ক্রমে করলে এমন একটি জানালা থাকে যখন কেউ CIDR ব্লকের টাইপো ঠিক করতে API সার্ভারে পৌঁছাতে পারে না।

অনুমোদিত তালিকা কখনো যা ঢাকেনি

এটি API সার্ভারকে ব্যক্তিগত করে না। একটি প্রাইভেট ক্লাস্টার প্রাইভেট এন্ডপয়েন্ট ও প্রাইভেট DNS ব্যবহার করে, আর অনুমোদিত-রেঞ্জ তালিকা তা প্রতিস্থাপনকারী নিয়ন্ত্রণ নয়। এটি অনুমোদিত কলকারী কী করতে পারবে তাও বদলায় না, তাই ফাঁস হওয়া অ্যাডমিন kubeconfig যেকোনো অনুমোদিত ঠিকানা থেকে এখনো কাজ করে। ক্রেডেনশিয়ালকে নিরাপত্তার সীমা আর তালিকাকে নেটওয়ার্কের সুবিধা হিসেবে ধরুন।

এর সঙ্গে ওয়ার্কলোডের কোনো সম্পর্ক নেই। তালিকা চালু থাকলেও Pods ও Services চলতে থাকে, আর VPN-এর উপর দিয়ে কোনো অ্যাপ্লিকেশনে পৌঁছানো আলাদা সমস্যা: যে Service-এর কেবল ক্লাস্টার IP আছে, ল্যাপটপ সেটি খুলতে পারার আগে তার এখনো একটি অভ্যন্তরীণ লোড ব্যালান্সার, একটি ingress বা একটি port-forward দরকার। ওই দুই ডিজাইন মেশালে এমন একটি পরিবর্তন-টিকিট তৈরি হয় যা ডেভেলপারদের সীমিত করার দাবি করে অথচ অ্যাপ্লিকেশন সম্পর্কে আসলে কিছুই সীমিত করে না।

দুই দিক থেকেই যাচাই করুন, তারপর একটি বাস্তব অপারেশন চালান

VPN-এ একটি নতুন ক্লায়েন্ট এবং তার বাইরের একটি ক্লায়েন্ট দিয়ে পরীক্ষা করুন। বাইরের প্রচেষ্টা নাম রেজলিউশনে নয়, API সার্ভারে প্রত্যাখ্যাত হওয়া উচিত; যদি নামটি রেজলভ না হয়, তবে আপনি DNS পরীক্ষা করছেন এবং ফিল্টার সম্পর্কে কিছুই শেখেননি। এরপর এমন একটি অপারেশন চালান যা ইন্টারঅ্যাকটিভ kubectl কল নয়, যেমন একটি নোড পুল স্কেল বা একটি আপগ্রেড পরীক্ষা, এবং এটি সম্পন্ন হবে বলে ধরে নেওয়ার বদলে সম্পন্ন হওয়া নিশ্চিত করুন।

পরিবর্তনের পাশে আগের তালিকার মান লিখে রাখুন, এবং টাইপ করা কমান্ডে ভরসা না করে হালনাগাদের পরে কার্যকর মান আবার পড়ুন। AKS অনুমোদিত IP রেঞ্জ ডকুমেন্টেশন সমর্থিত প্যারামিটার এবং একই তালিকায় থাকা প্ল্যাটফর্মের প্রয়োজনীয়তা তালিকাভুক্ত করে, আর বেশিরভাগ টিকিট বিবরণ এই অংশটিই বাদ দেয়।