Ставете го EKS API зад VPN: редослед на операциите

Овозможете ја приватната крајна точка, докажете дека kubectl стигна до неа, потоа затворете јавната. Чекор-по-чекор runbook со командите и проверките помеѓу секој чекор.

Опасната верзија на оваа промена е една команда која ја превртува крајната точка и ги заклучува сите администратори во исто време. Безбедната верзија ги држи двата пата отворени, докажува дека приватниот работи од 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

Задржете го името на домаќинот и проверката на сертификатот точно како што се. Замената со приватна IP во kubeconfig и прескокнувањето на 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, потоа тестирајте го патот за обновување еднаш додека сето уште е лесно.

Поврзани статии