Контекст: У меня есть кластер EKS (EKS - это управляемый сервис AWS kubernetes). Я внедряю приложение в этот кластер EKS (JupyterHub) через helm. У меня есть VPN-сервер. Пользователи моего приложения (JupyterHub на EKS) должны подключиться к серверу VPN, прежде чем они получат доступ к приложению. Я применяю это, удалив правило входа 0.0.0.0/0 «разрешить все» на эластичном балансировщике нагрузки и добавив правило входа, разрешающее трафик только с VPN-сервера. Упоминаемый выше эластичный балансировщик нагрузки создается неявно приложением JupyterHub, которое развертывается в EKS через helm.
Проблема: Когда я внедряю изменения в работающее приложение JuypyterHub в EKS, иногда [в зависимости отоб изменениях] ELB удаляется и воссоздается. Это приводит к тому, что группа безопасности, связанная с ELB, также создается заново вместе с правилами входа. Это не идеально, потому что это легко игнорировать при развертывании изменений в JupyterHub / EKS, и разработчик может забыть убедиться, что правила группы безопасности все еще присутствуют.
Вопрос: Есть либолее надежное место, где я могу применить это правило входящей сети (разрешать трафик только с VPN-сервера)?
Две мысли, которые у меня были, но не идеальные:
- Использовать NACL. Это не сработает, потому что это добавляет много накладных расходов на управление CIDR из-за того, что NACL является состоянием и работает на уровне подсети.
- Я подумал добавить свои правила входа в группу безопасности, связанную сВместо этого рабочие узлы EKS, но это не сработает из-за той же проблемы. Когда вы вносите обновление в Jupyterhub / EKS и если заменяется ELB, правило входа «разрешить весь трафик» неявно добавляется в группу безопасности рабочего узла EKS (разрешая весь трафик из ELB). Это переопределит мое правило входа.