Почему NLB в AWS не требует группы безопасности?

Question

В AWS при настройке балансировщиков нагрузки типа CLB и ALB необходимо обязательно связать группу безопасности. Эта ассоциация помогает ограничить тип трафика c для балансировщика нагрузки. Почему для NLB не требуется группа безопасности? Разве это не угроза безопасности? Я знаю, что лучшим предположением здесь может быть - «AWS спроектировал это таким образом», но их документация, похоже, не объясняет аргументы / преимущества исключения конфигурации группы безопасности для NLB.

Answer 1

NLB не исключение. NAT-шлюз также не имеет SG.

Основное различие между ALB, CLB и NLB (и NAT) состоит в том, что их сетевые интерфейсы (ENI) имеют разные Источник / назначение. проверьте настройку .

Для ALB и CLB Source/dest. check равно true. Для шлюзов NLB и NAT значение параметра false. Хотя я не знаю технических причин, по которым нет SG для CLB и NAT, я думаю, что отчасти причина может быть связана с настройками Source/dest. check:

Указывает, источник / место назначения выполняются проверки, где экземпляр должен быть источником или адресатом любого трафика c, который он отправляет или получает.

Таким образом, на мой взгляд, причина связана с назначением NAT и NLB, а не техническая неспособность AWS предоставить на них SG. Их основная цель - действовать как прокси. NLB и NAT обычно не мешают трафику c, а просто пропускают его. Это до пунктов назначения, чтобы определить, разрешен ли трафик c или нет. Таким образом, NAT и NLB не используют SG. У них единственный способ заблокировать входящий трафик c к ним - через NACL.

Напротив, ALB и CLB принимают активное участие в передаче трафика c, поскольку они проверяют все запросы. Следовательно, они также могут решить, разрешен ли трафик c или нет.

Answer 2

Я полагаю, что группа безопасности не требуется для балансировщика сетевой нагрузки (NLB), потому что он ведет себя прозрачно, сохраняя исходный IP-адрес для связанных целевых экземпляров. То есть вы по-прежнему можете указывать группы безопасности - но на целевом уровне напрямую, а не балансировщик нагрузки. Итак, концептуально , это не имеет большого значения (при использовании экземпляров EC2 за NLB) , где указаны SG. Хотя некоторые люди отмечают, что может быть сложно ограничить диапазон IP-адресов для проверки работоспособности NLB. [1] Более того, я думаю, что было бы удобнее указать правила группы безопасности один раз (централизованно) на балансировщике нагрузки, вместо того, чтобы прикреплять определенную группу безопасности c к каждому экземпляру EC2, который является целью NLB. Эти два можно рассматривать как недостатки NLB по сравнению с двумя другими балансировщиками нагрузки.

Технически NLB построен на совершенно новой технологии по сравнению с ALB / CLB. На некоторые различия указывает на reddit сотрудник AWS [2]:

На высоком уровне балансировщики нагрузки Classi c (CLB) и Application (ALB) представляют собой коллекцию ресурсов балансировки нагрузки, подключенных к вашему VP C с помощью набора сетевых интерфейсов Elasti c (ENI). У них есть слушатели, которые принимают запросы от клиентов и направляют их к вашим целям (ALB и NLB) / бэкэндам (CLB). В том же ключе Network Load Balancer (NLB) представляет собой аналогичную группу ресурсов балансировки нагрузки, подключенных к вашему VP C, но с использованием AWS Hyperplane ENI вместо обычного ENI. ENI Hyperplane - это распределенная конструкция, которая интегрируется с Software Defined Network (SDN) EC2 для прозрачного подключения нескольких базовых ресурсов балансировки нагрузки через один IP-адрес.

Все, кто не сделал Вы слышали термин «гиперплоскость» раньше, не стесняйтесь проверить соответствующий сеанс re: Invent. [3] Hyperplane используется для NAT Gateway, PrivateLink и улучшенного VP Lambda C Networking [4].

Учитывая, на что способна Hyperplane, а также учитывая тот факт, что он построен на EC2, я не вижу причин, по которым AWS не смог бы реализовать SG для NLB, если бы захотел. Я согласен с @Marcin, что это, вероятно, намеренно.

[1] https://forums.aws.amazon.com/thread.jspa?threadID=263245 [2] https://www.reddit.com/r/aws/comments/cwbkw4/behind_the_scenes_what_is_an_aws_load_balancer/#t1_eyb2gji [3] https://www.youtube.com/watch?v=8gc2DgBqo9U#t = 33 мин. 40 сек. [4] https://aws.amazon.com/de/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/

Answer 3

NLB работает на четвертом уровне модели OSI, связь проходит через балансировщик сетевой нагрузки, а детали подключения достигают цели, в этом случае экземпляры EC2 получают IP-адрес клиента, а группа безопасности экземпляра должна разрешить IP-адреса исходного клиента.

ALB работает на седьмом уровне модели OSI, связь достигает прослушивателя ALB, а затем он открывает соединение с целевыми объектами, экземпляр EC2 получает IP-адреса ALB вместо IP-адресов клиентов

Для получения дополнительных сведений https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html

https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html