Поместите 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, затем один раз проверьте путь восстановления, пока это ещё легко.

Похожие статьи