Сквозная передача SSL в AWS Network Load Balancer

Question

Я пытаюсь обеспечить полное соединение e2e между клиентами и моими внутренними серверами. Вот так выглядит моя текущая инфраструктура:

1. Кластер Fargate с моими серверными приложениями, размещенными в частных подсетях.
2. Они обслуживаются внутренним балансировщиком сетевой нагрузки, который также не подвергается воздействию внешнего мира.
3. REST API Gateway с интеграцией канала VPC с моим внутренним NLB.

В настоящее время мой NLB использует прослушиватель TLS на порту 443 и имеет прикрепленный сертификат, но завершает TLS и связывается со своей целевой группой вяло по TCP на порту 80. Я планирую настроить TLS и сертификаты также на моих узлах Fargate. В настоящее время я не понимаю, как будет работать следующая установка. Собирается ли он отправлять зашифрованный трафик от моих клиентов в серверные приложения или, скорее, выполнять дешифрование на NLB и еще раз зашифровать трафик перед его отправкой на узлы Fargate?

Я узнал, читая много блогов, что можно добиться сквозного поведения с использованием NLB без расшифровки / шифрования трафика на NLB, но не нашел никаких примеров, также документация AWS не совсем ясна по этой теме.

Возможно ли, чтобы сертификаты применялись только к моим серверным приложениям, а расшифровка происходила только там? Насколько я понимаю, я мог бы выглядеть примерно так:

1. Сертификаты и TLS настроены на стороне моих приложений Fargate
2. NLB с прослушивателем TCP на порту 443, сертификаты на уровне NLB не применяются. Таким образом, NLB будет передавать только зашифрованный трафик от моих клиентов на серверную часть.

Кто-нибудь пробовал настроить подобную инфраструктуру и знает, как это нужно настраивать?

С Уважением.

Answer 1

Я верю, что твое предположение верно, Ярек. Вам также необходимо создать NLB с TCP Listener на 443 и TCP TargetGroup. Контейнер ECS, который вы развертываете (Fargate или что-то еще), будет получать запрос TLS, выполнять согласование рукопожатия и т. д. Ваш прослушиватель NLB на самом деле является проходом TCP, если вы будете использовать порт 443, а контейнер ECS выполняет фактический TLC. Работа. Для контейнера ECS вы, вероятно, захотите использовать SecretsManager для хранения сертификата, ключа и цепочки.

Если вам также требуется проверка сертификата клиента (mTLS), вы также захотите сохранить любые дополнительные цепочки, которые могут вам понадобиться для проверки сертификата клиента.

Недостатком этой настройки NLB является то, что вы теряете некоторые функции прослушивателя NLB TLS, такие как ограничения протоколов TLS, которые он может применять. Вы можете сделать это на своем контейнере ECS самостоятельно, но контейнер станет более сложным.

Одно предостережение, о котором следует помнить, заключается в том, что функциональность «сохранения IP-адреса клиента», которую может выполнять TargetGroup, нарушит вашу целевую группу. Пока не придумал, как это обойти. Пока не удалось заставить это работать с этой настройкой.

Кроме того, я подозреваю, что есть способ создать прослушиватель TLS, соответствующий TLS TargetGroup с контейнером ECS с поддержкой TLS, но мне это кажется избыточным и трудным для правильной настройки, поскольку расшифровка будет происходить на NLB, а затем будет повторно шифроваться для Целевая группа TLS и контейнер ECS. Я не совсем уверен, как это может работать, если вообще работает. Насколько я понимаю, AWS ELBv2 ALB и NLB не проверяют какие-либо сертификаты TLS за ними (требуется ссылка). Я лично не смог заставить это работать правильно.

Answer 2

Добавление ссылки на сообщение AWS, показывающее, как настроить сквозную передачу SSL с NLB без завершения TLS с использованием дополнительного перехода ALB, https://repost.aws/questions/QU94k_s2LyRd-hJRloOlzAwQ/is-it-possible-to-setup-a- пересылка-nlb-в-alb-с защищенной конечной точкой-nlb.

Надеюсь, это поможет!