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-ის ასოციაცია, site-to-site კარიბჭე და 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 ენდპოინტების დოკუმენტაცია ღირს ერთხელ სრულად წაკითხვა, რადგან მასში ნათქვამია, რომ მხოლოდ კერძო წვდომა შეიძლება მოვიდეს 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-მდე მისასვლელად. ჩაწერეთ საბოლოო მდგომარეობა, თარიღი და აღდგენის გზა runbook-ში, შემდეგ ერთხელ გამოსცადეთ აღდგენის გზა, სანამ ჯერ კიდევ ადვილია.