Amazon Web Services объявила о важном обновлении своего управляемого Kubernetes-сервиса — Elastic Kubernetes Service (EKS). Теперь стала доступна полная приватная сеть (Full Private Networking) для кластеров. Это значит, что весь трафик между control plane и worker nodes может быть замкнут исключительно в вашем Amazon VPC, без прохождения через публичные IP-адреса или интернет-шлюзы.
Что изменилось?
Ранее EKS control plane был доступен через публичный endpoint, хотя можно было ограничить доступ с помощью security groups. С новым режимом администраторы могут создать кластер, где ни один компонент не имеет публичного IP. Control plane размещается внутри VPC, и все коммуникации — от kubelet до apiserver, от kubectl до API — идут по приватным адресам.
Технически это реализовано через AWS PrivateLink и эластичные сетевые интерфейсы (ENI), которые подключаются к подсетям вашего VPC. Для работы достаточно указать приватные подсети при создании кластера — и control plane становится полностью внутренним.
Технические детали, которые стоит знать
Требования к сети:
- VPC должна иметь не менее двух приватных подсетей в разных зонах доступности (AZ).
- Подсети должны быть с маской не менее /28 (минимум 8 свободных IP на подсеть).
- Необходимо разрешить исходящий трафик к сервисам AWS (API, S3, ECR, CloudWatch и т.д.) через VPC endpoint или NAT Gateway.
- Для доступа к кластеру извне (например, через kubectl) придётся использовать VPN, Direct Connect или bastion host.
Совместимость:
- Полная приватная сеть доступна для новых кластеров EKS с версией 1.25 и выше.
- Миграцию существующего кластера из публичного режима в приватный пока выполнить нельзя — потребуется пересоздать кластер.
- Режим поддерживает все стандартные аддоны (CoreDNS, kube-proxy, VPC CNI), но может потребоваться настройка меток и ролей для работы с приватными DNS.
Производительность:
- Трафик внутри VPC идёт с минимальной задержкой, без прохождения через интернет — это может уменьшить латентность на 1-3 мс.
- Пропускная способность ограничена только возможностями ENI и инстансов EC2.
Что это значит для админов и владельцев инфраструктуры?
Для DevOps-инженеров и SRE это инструмент для построения действительно защищённых пайплайнов. Теперь можно:
- Размещать кластеры в полностью изолированных VPC без выхода в интернет.
- Соблюдать требования PCI DSS, SOC 2, HIPAA — когда трафик управления не должен покидать периметр.
- Использовать kubectl через AWS Session Manager или System Manager — без открытия SSH-портов.
- Снизить риск утечки данных через контрольную плоскость — атаки на публичный API-сервер становятся невозможными.
Для владельцев сайтов на EKS это дополнительный уровень безопасности без изменения кода приложений. Однако нужно помнить, что все сервисы, которые полагаются на внешние вебхуки или CI/CD, потребуют настройки приватного доступа — через VPC endpoints или Proxy.
Практические выводы
- Планируйте архитектуру заранее — после создания кластера сменить тип сети нельзя. Если вы не уверены, используйте публичный endpoint с ограничением доступа по IP, а потом мигрируйте.
- Настройте VPC endpoints — для ECR, S3, CloudWatch и других сервисов AWS, чтобы ноды не зависели от NAT Gateway (экономия денег и пропускной способности).
- Используйте AWS IAM Roles for Service Accounts (IRSA) — это снижает необходимость в передаче credentials и упрощает аудит.
- Проверьте логи — CloudTrail и VPC Flow Logs помогут убедиться, что трафик идёт строго по приватным маршрутам.
- Рассмотрите hybrid-режим — если часть вашего пайплайна (например, внешний CI/CD) не может работать без доступа к публичному API, можно оставить публичный endpoint, но запретить входящий трафик с недоверенных IP.
Полная приватная сеть в EKS — это зрелый шаг к Zero Trust и defence-in-depth для Kubernetes. Она не решит все проблемы безопасности, но устраняет целый класс атак на уровень управления. Переход стоит запланировать при создании новых проектов — особенно для финансовых и медицинских нагрузок.
А ваш текущий кластер всё ещё смотрит в интернет? Возможно, пора подумать о миграции.