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

Активирайте частния endpoint, докажете, че kubectl го достига, след което затворете публичния. Поетапен runbook с командите и проверките между всяка стъпка.

Опасната версия на тази промяна е една команда, която обръща endpoint-а и заключва всеки администратор едновременно. Безопасната версия оставя двата пътя отворени, доказва, че частният работи от VPN, и едва след това извежда от експлоатация публичния endpoint. Приемете съществуващ клъстер, одобрен тунел към неговия VPC и kubeconfig, който вече работи; задачата е частен достъп до API на Kubernetes, а не частни възли и не нов модел на разрешения. Всяка стъпка по-долу има проверка, при която можете да се провалите безопасно.

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-а, а групата за сигурност на клъстера — от TCP 443 от източника, който VPN всъщност представя. Client VPN асоциация, site-to-site шлюз и peered 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-то на актуализацията, докато отчете успех, вместо да чакате фиксиран брой секунди и да предполагате. Оставете трафика на възлите и контролната плоскост на мира, докато правите това: заменянето на цялата група за сигурност на клъстера с правило за вашия лаптоп е начинът работещата плоскост на данни да стане втори инцидент.

Документацията за endpoint-ите на EKS си струва да се прочете веднъж изцяло, защото в нея се казва, че достъп само през частен път може да идва от 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

Запазете името на хоста и проверката на сертификата точно както са. Замяната с частен IP в kubeconfig и пропускането на TLS проверката не е миграцията, която описахте в записа за промяната, и тя ще се провали отново в момента, в който endpoint-ът се завърти.

4. Изведете публичния достъп от експлоатация умишлено

След като частният път е демонстриран и процесът за възстановяване е одобрен, затворете публичния endpoint. Това е реална промяна, а не преглед, затова я изпълнете върху акаунта и настройките, които наистина имате предвид.

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true

В режим само частен достъп публичното DNS име се разрешава до частните адреси на endpoint-а отвътре във VPC, така че разрешаването и достъпността престават да бъдат едно и също нещо. Всичко, което разчиташе на публичния адрес, включително CI runner-и или лаптоп в друга мрежа, сега се нуждае от свой собствен път навътре.

5. Дръжте мрежовата политика и политиката за идентичност отделно

Списъкът с CIDR за публичен достъп управлява само публичния endpoint. Той не ограничава частния endpoint, който вместо това се ограничава от групата за сигурност на клъстера и политиката на свързаната мрежа. Ако запазите публичния endpoint, неговият списък с разрешени адреси трябва да съответства на публичния изход, който вашите API клиенти и възли всъщност използват; адрес от VPN пул рядко е този източник.

Нищо от това не променя IAM или Kubernetes RBAC. Настройките на endpoint-а са административно действие и обикновените потребители не трябва да получават разрешение да разхлабят границата само за да достигнат API. Запишете крайното състояние, датата и пътя за възстановяване в runbook-а, след което тествайте пътя за възстановяване веднъж, докато е още лесно.

Подобни статии