EKS API-ін VPN артына қою: операциялар реті

Жеке endpoint-ті қосыңыз, kubectl оған жеткенін дәлелдеңіз, содан кейін жалпыға ашық endpoint-ті жабыңыз. Әр қадамның арасындағы командалар мен тексерулері бар кезеңдік runbook.

Бұл өзгерістің қауіпті нұсқасы — 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-тің жеке мекенжайларына маршрут керек, ал кластердің қауіпсіздік тобына 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

Жаңарту асинхронды. Белгілі бір секунд санын күтіп болжаудың орнына жаңарту 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-ге жету үшін ғана шекараны босатуға рұқсат алмауы керек. Соңғы күйді, күнді және қалпына келтіру жолын runbook-қа жазыңыз, содан кейін қалпына келтіру жолын әлі оңай кезде бір рет тексеріңіз.

Қатысты мақалалар