რატომ მუშაობს kubectl VPN-ით, მაგრამ AKS სკალირებას წყვეტს

თქვენ ამატებთ ოფისის VPN-ის საჯარო მისამართს AKS API სერვერის ნებადართულთა სიაში და kubectl მუშაობს. ერთი კვირის შემდეგ node pool-ის სკალირება ვერ ხერხდება, CI დავალება ვერ აღწევს კლასტერამდე, და პორტალი აჩვენებს შეცდომას, რომელშიც IP დიაპაზონებზე არაფერია ნათქვამი. ნებადართულთა სია არავის შეუცვლია. თქვენ მიერ ჩართული კონტროლი API სერვერის წინ მდგომი საჯარო IP ფილტრია და მან არ იცის ვინ რეკავს, მხოლოდ იმას იცის, თუ რომელი მისამართიდან მოვიდა ზარი. VPN არის ერთი მისამართი იმ რამდენიმედან, რომლებიც კლასტერს სჭირდება, და იშვიათად სწორედ ის ირღვევა პირველი.

ნებადართულთა სია მისამართს ემთხვევა, არა ადამიანს

--api-server-authorized-ip-ranges ის იღებს CIDR ბლოკებს და არა მომხმარებლებს ან ჯგუფებს. როცა დეველოპერის მოთხოვნა ტოვებს VPN სერვერს Azure-ისკენ, API სერვერზე წყაროს მისამართი VPN სერვერის საჯარო გასასვლელია. ამიტომ ამ VPN-ზე ყველა ადამიანი ერთ ჩანაწერს იზიარებს, და VPN-ის გარეთ მყოფ ნებისმიერს უარს ეუბნებიან ჯერ კიდევ ავთენტიფიკაციამდე.

ეს ნიშნავს იმასაც, რომ ჩანაწერი უფრო მეტ ადამიანს უშვებს, ვიდრე გგონიათ. VPN წვდომის მქონე კონტრაქტორი, იმავე კონცენტრატორზე მდგომი პირადი ნოუთბუქი და გატეხილი ანგარიში ყველა ერთი და იმავე მისამართიდან მოდის. კლასტერის ავტორიზაცია არ შეცვლილა, ამიტომ როლზე დაფუძნებული წვდომის კონტროლი კვლავ წყვეტს, რა შეიძლება გააკეთოს დამრეკმა, მაგრამ ნებადართულთა სია პირადობის კონტროლი არ არის და არასდროს არ უნდა აღიწეროს როგორც ასეთი.

პირველი, რაც ირღვევა, ჩვეულებრივ kubectl არ არის

ნებადართულთა სია ვრცელდება API სერვერის საჯარო ბოლო წერტილზე, ამიტომ თქვენს ჩამოთვლილ მისამართებს გარეთ ყველაფერი მაშინვე წყვეტს მუშაობას. აშკარა მსხვერპლები არიან VPN მარშრუტის გარეშე დარჩენილი მეორე ოფისი, ჰოსტინგურ გზაზე მყოფი CI runner და ნოუთბუქი, რომელსაც დაკავშირება დაავიწყდა. მათი ამოცნობა ადვილია, რადგან ადამიანი ელოდება.

ნაკლებად აშკარა შემთხვევაა ავტომატიზაცია, რომელსაც 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-იდან; საპირისპირო რიგით კეთება ტოვებს ფანჯარას, სადაც ვერავინ ვერ აღწევს API სერვერამდე CIDR ბლოკში ბეჭდვითი შეცდომის გამოსასწორებლად.

რა არასდროს დაფარა ნებადართულთა სიამ

ის API სერვერს პირადს არ ხდის. პირადი კლასტერი იყენებს პირად ბოლო წერტილს და პირად DNS-ს, და ავტორიზებული დიაპაზონების სია არ არის ის კონტროლი, რომელიც მას ცვლის. ის ასევე არ ცვლის, თუ რა შეუძლია შეშვებულ დამრეკს, ამიტომ გაჟონილი ადმინის kubeconfig მაინც მუშაობს ნებისმიერი ნებადართული მისამართიდან. მოეკიდეთ სერტიფიკატს როგორც უსაფრთხოების საზღვარს, ხოლო სიას როგორც ქსელურ კომფორტს.

მას საერთო არაფერი აქვს სამუშაო დატვირთვებთან. Pods და Services აგრძელებენ მუშაობას სიის ჩართული მდგომარეობით, და VPN-ით აპლიკაციამდე მისვლა ცალკე პრობლემაა: Service-ს, რომელსაც მხოლოდ კლასტერის IP აქვს, ჯერ კიდევ სჭირდება შიდა დატვირთვის გამანაწილებელი, ingress ან port-forward, სანამ ნოუთბუქი გახსნის მას. ამ ორი დიზაინის შერევა წარმოშობს ცვლილების ბილეთს, რომელიც ამტკიცებს, რომ ზღუდავს დეველოპერებს და სინამდვილეში აპლიკაციებზე არაფერს ზღუდავს.

გადაამოწმეთ ორივე მხრიდან, შემდეგ შეასრულეთ ერთი რეალური ოპერაცია

გამოსცადეთ VPN-ზე ახალი კლიენტით და მის გარეთ მყოფი კლიენტით. გარე მცდელობა უნდა უარყოფილ იქნას API სერვერზე და არა სახელების გარჩევისას; თუ სახელი არ იხსნება, თქვენ DNS-ს ამოწმებთ და ფილტრის შესახებ არაფერი ისწავლეთ. შემდეგ შეასრულეთ ოპერაცია, რომელიც ინტერაქტიული kubectl გამოძახება არ არის, მაგალითად node pool-ის სკალირება ან განახლების შემოწმება, და დაადასტურეთ, რომ ის სრულდება და არა ჩათვალეთ, რომ დასრულდება.

შეინახეთ წინა სიის მნიშვნელობა ცვლილების გვერდით და განახლების შემდეგ ხელახლა წაიკითხეთ ეფექტური მნიშვნელობა, ნაცვლად იმისა, რომ აკრეფილ ბრძანებას დაეყრდნოთ. AKS-ის დოკუმენტაცია ნებადართული IP დიაპაზონების შესახებ ჩამოთვლის მხარდაჭერილ პარამეტრებს და პლატფორმის მოთხოვნებს, რომლებიც იმავე სიას ეკუთვნის, და სწორედ ამ ნაწილს ტოვებს ბილეთების აღწერილობების უმეტესობა.