Сервисы ECS Fargate в AWS VPC - невозможно общаться друг с другом

Моя архитектура похожа на

Route53 -> SG -> ALB -> Target Group (IP) -> Task.

В Route 53 у меня определены пространства имен. Один публичный, а другой частный.

domain.io   ----   Private
domain.io   ----   Public

У меня есть две службы: A и B.

ALB выглядят так:

<DNS of public LB attached to service A> = A-ALB
<DNS of public LB attached to service B> = B-ALB

В частном пространстве имен записи выглядят так:

service-a.domain.io - Type A record - A-ALB
service-b.domain.io - Type A record - B-ALB

В пространстве имен Public записи выглядят так:

service-a.domain.io - Type A record - A-ALB
service-b.domain.io - Type A record - B-ALB

A-ALB и B-ALB имеют прикрепленную к ним группу безопасности. Эта группа безопасности содержит блок CIDR VPC, чтобы разрешить прохождение всего входящего трафика от VPC.

All traffic ---- All  ----  All ---  10.0.0.0/16

Задания:

Task        Private IP        Public IP        
A           10.0.0.1          3.0.0.1
B           10.0.0.2          3.0.0.2

Когда служба A вызывает службу B по URL-адресу service-b.domain.io, она берет значение из частного пространства имен и пытается получить доступ к задаче через целевую группу. Но поскольку там указан балансировщик нагрузки, служба A пытается получить доступ к службе B, используя общедоступный IP-адрес службы A. А общедоступный IP-адрес службы A (3.0.0.1) не указан в группе безопасности, время ожидания истекает, и мы не получаем ответа. Но когда я занесу этот IP-адрес в белый список, служба A сможет без проблем получить доступ к службе B.

Поскольку балансировщик нагрузки является общедоступным балансировщиком нагрузки, он разрешает общедоступный IP-адрес задачи. Служба B позволяет мне подключать только один балансировщик нагрузки, частный или общедоступный. Так как эта служба также должна быть доступна публично, мне определенно нужно выбрать общедоступный балансировщик нагрузки.

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

Как следует обслуживать службу доступа A B, чтобы не требовать изменения группы безопасности? Стоит ли вносить изменения в Route 53? ALBs? ТГ? Или сервис?


person kChak    schedule 26.07.2020    source источник
comment
Я думаю, что идеальным решением было бы рассмотреть возможность использования обнаружения служб [1], если ваша архитектура позволяет. [1] - docs.aws.amazon.com/AmazonECS/ latest / developerguide /   -  person Ali    schedule 26.07.2020
comment
Я попытался использовать обнаружение служб, но поскольку у меня есть порт, связанный с моим приложением, он создает запись SRV на маршруте 53, и DNS не может решить эту проблему.   -  person kChak    schedule 26.07.2020
comment
Я просто хотел указать, что в большинстве случаев ваш сервис должен быть приватным с балансировщиком нагрузки. Если ваша служба является общедоступной, то кто-то теоретически может попасть в нее напрямую, и если у вас отключен HTTPS в ALB, они могут это обойти. Просто укажите общедоступные подсети ALB в том же VPC, что и служба, но предоставьте служебные частные подсети.   -  person GoForth    schedule 19.04.2021


Ответы (1)


Похоже, у вас есть общедоступный ALB, который не должен быть общедоступным, поскольку общедоступные балансировщики нагрузки обычно имеют правило 0.0.0.0/0 в группе безопасности, что позволяет избежать проблемы, с которой вы столкнулись.

Я бы посоветовал вам создать внутренний балансировщик нагрузки вместо общедоступного балансировщика нагрузки.

Таким образом, когда произойдет разрешение DNS для ALB DNS, будет возвращен частный IP-адрес ALB, и, следовательно, связь будет происходить внутри, вы можете указать идентификатор группы безопасности (как источник) в группе безопасности.

person shariqmaws    schedule 26.07.2020
comment
Я подумал об этом, но что, если я хочу, чтобы приложение было доступно как изнутри, так и извне? - person kChak; 26.07.2020