Розмістіть 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 і піринговий 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-раннери або ноутбук в іншій мережі, тепер потребує власного шляху всередину.

5. Тримайте мережеву політику й політику ідентичності окремо

Список CIDR публічного доступу керує лише публічним endpoint. Він не обмежує приватний endpoint, який натомість обмежується групою безпеки кластера й політикою під'єднаної мережі. Якщо ви залишаєте публічний endpoint, його список дозволених має відповідати публічному виходу, який реально використовують ваші клієнти API та вузли; адреса пулу VPN рідко буває цим джерелом.

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

Схожі статті