Architecture-center: Защитите сетевой поток - как это будет работать

Благодарим за сообщение - эта проблема находится на рассмотрении. Это идентификатор ошибки Microsoft Internal DevOps AB # 271079.

Спасибо, что обратились к @melzayet. Два потока трафика имеют разные источники. Верхний (зеленый) поток - это HTTP-трафик, предназначенный для рабочих нагрузок вашего кластера (веб-приложение / api и т. Д.), Выполняемых на узлах в кластере. HTTP-ответ на эти запросы будет возвращен в WAF и клиенту.

Нижний (оранжевый) поток - это трафик, исходящий из подсети, содержащей узлы. Это будет трафик, исходящий во внешние реестры контейнеров, сервер API Kubernetes и т. Д. Практически любой трафик, исходящий из кластера, который мы хотим защитить с помощью наших корпоративных правил выходного брандмауэра.

Поскольку трафик исходит из-за пределов сети, управляемой UDR, и тот факт, что мы используем _внутренний_ балансировщик нагрузки в отдельной подсети, он принимает тот же путь возврата. Правило UDR применяется к трафику, исходящему в его области.

Кроме того , чтобы быть ясно, это решение , представленное решает для выходного строгой изоляции (как определено , как трафик , исходящий из кластера) только, оно не воронка как вход и выход через брандмауэр.

Я предполагаю, что часть DNAT, о которой вы говорите, взята из этого раздела в документации AKS (в частности, этого ). В этом случае они также заставляют весь входящий трафик проходить через брандмауэр. В их случае они используют _public_ балансировщик нагрузки для входа, наше решение НЕ использует общедоступный балансировщик нагрузки для входа. Мы устанавливаем контакт с AAG, который затем маршрутизируется через _внутренний_ балансировщик нагрузки в выделенной входящей подсети, которая не будет подвергаться асимметричной маршрутизации. Если вы предоставили свои сервисы напрямую через IP-адрес общедоступного балансировщика нагрузки, то наверняка столкнетесь с проблемой асимметричной маршрутизации.

Дайте мне знать, если я смогу что-то прояснить - я знаю, что это кажется немного "противоречащим интуиции". Не стесняйтесь развертывать с использованием эталонной реализации, в конце этого путешествия у вас будет веб-сайт, на котором HTTP-трафик рабочей нагрузки обрабатывается через входящий маршрут (Клиент -> WAF -> внутренний LB -> nodepool -> WAF -> Клиент) и исходящий из кластера трафик (nodepool -> FW -> внешний ресурс -> FW -> nodepool) обрабатывается через исходящий маршрут.

@ckittel Спасибо, что поделились своим поводу ! Поручаю вам этот вопрос.

@ckittel большое спасибо за подробный и информативный ответ. Я думаю, что мое замешательство возникло из-за асимметричного вопроса, но вы очень хорошо прояснили его. Еще раз спасибо, что нашли время