RDS publi c доступ потерян при добавлении publi c su bnet со шлюзом inte rnet и частными подсетями с NAT - PullRequest
1 голос
/ 01 апреля 2020

Любая помощь будет принята с благодарностью!

Изначально у нас было 3 подсети в нашей AWS VP C. VP C имеет IGW и одну таблицу маршрутов по умолчанию с 2 маршрутами - 1 для внутреннего и 0.0.0.0/0 для IGW. Стандартная начальная настройка VP C.

Внутри VP C у нас есть экземпляр RDS с прокси-сервером RDS, а в БД настроен доступ publi c при разработке решения. БД связана с VP C SG по умолчанию вместе со специфицированным c SG, который вносит белый список IP-адресов для подключения к БД через конечную точку publi c.

Также в VP C мы имеем Lambda, которая использует группу безопасности VP C по умолчанию и 3 подсети, упомянутые выше.

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

Проблема:

Теперь нам нужно предоставить Lambda доступ к inte rnet (он должен соединяться с RedisLabs). Для этого мы добавили:

  • Publi c su bnet (su bnet -00245f33edbae3358)
  • NAT на паблике c su bnet
  • Создана таблица маршрутов, связанная с существующими 3 частными подсетями (su bnet -06d1124e, su bnet -ba82bce1, su bnet -3344b955) с маршрутом 0.0.0.0/0 -> NAT
  • Создана таблица маршрутов, связанная с новым publi c su bnet (su bnet -00245f33edbae3358) с маршрутом 0.0.0.0/0 -> IGW

В этом месте Lambda может по-прежнему обращаться к БД через прокси-сервер RDS (ожидается) и теперь может обращаться к inte rnet (ожидается), НО мы теряем соединение с БД через конечную точку публикации c. .

Чего-то не хватает в конфигурации, которая позволит Lambda получить доступ к RDS и inte rnet И также позволит нам получить доступ к RDS через конечную точку publi c? ИЛИ Для этого нам нужен туннель S SH в паблике c su bnet?

Заранее спасибо!

Дополнительная информация:

В настоящее время RDS имеет следующие SG: - prod-auth-service-rds - разрешает TCP 3306 с моего белого списка IP-адресов - sg-11cb746b (по умолчанию) - все трафики c с самореференсным источником (sg-11cb746b)

RDS находится в подсетях: - su bnet -06d1124e - существующая частная подсеть - su bnet -ba82bce1 - существующая частная подсеть - su bnet -3344b955 - существующая частная su bnet

NAT на su bnet su bnet -00245f33edbae3358

Ответы [ 2 ]

0 голосов
/ 03 апреля 2020

Оказывается, все, что мне нужно было сделать, - это создать лямбду в частных su bnet (s) отдельно от существующих подсетей RDS. Отдельные su bnet (s) затем нуждаются в маршруте, который перенаправляет 0.0.0.0/0 в NAT.

Теперь Lambda имеет доступ outbout inte rnet и доступ RDS, в то время как экземпляр RDS все еще может быть достигнут через существующую конечную точку publi c.

0 голосов
/ 02 апреля 2020

РЕДАКТИРОВАТЬ: Перечитайте ваш ответ, если ваша БД RDS находится в частных подсетях, тогда она не может быть общедоступной независимо от того, что вы указали в качестве этой опции в настройках БД.
——-

После просмотра дополнительной информации, я считаю, что проблема в вашей группе безопасности для RDS. Он разрешает только трафик c из вещей в вашей группе безопасности по умолчанию или в вашем персональном белом списке IP-адресов.

Даже если лямбда-выражение входит в вашу группу безопасности по умолчанию, RDS видит траффи c как исходящую от вашей лямбды, они видят его как входящий из NAT Gataway, который не имеет и групп безопасности.

Вы можете решить эту проблему, добавив EIP вашего шлюза NAT в качестве дополнительного белого списка IP-адресов к вашим правилам входящего трафика RDS SG.

...