Какие Best practices по применению private zones в сервисе AWS Route53?

Question

[Alex Rodridez]

Существует автопарк EC2, который должны разговаривать друг с другом внутри инфраструктуры а некоторые тазики еще и отвечать на запросы извне. Вопрос: нужно ли настраивать private zone(aws.local) и цеплять сервисы на сабдомены(ubuntu1.aws.local) для адресации сообщений внутри сети? Как тогда привязать SSL certificate в этом случае чтоб все было секьюрно?
Или достаточно юзать Elastic IP для каждой машинки + AWS Certificate manager + route53(public zone) и все это закрыть секьюрити группами?

Answer 1

[Евгений Хлебников]

1.
не совсем ясно как организована ваша инфраструктура
Судя по тому, что у вас есть вариант "назначить публичные IP и рулить публичными ДНС именами" - все располагается в default vpc и это не best practice.
Рекомендуется размещать инстансы, к которым не нужен доступ из интернета (те, которые хостят ваши сервисы, обслуживающие только ваши другие сервисы в том же VPC) в приватных подсетях VPC.
Вообще рекомендуется ВСЕ сервисы размещать в приватных подсетях а доступ из интернета к ним организовывать, используя прокси. AWS предоставляет ALB(ELB\NLB в зависимости от ваших потребностей), или же вы можете поднять свой прокси (HAProxy, NGINX или другие) на ec2 инстансе, расположенном в публичной подсети
2.
Route53 private zone
Если ваши сервисы находятся в приватной подсети и вам необходимо работать с ними по DNS именам: можно регистрировать инстансы в Route53 private zone или же поднять свой приватный DNS на любом ПО которое вы умеете(в таком случае необходима перенастройка параметров VPC в котором вы работаете, чтобы все сервисы могли работать с вашим DNS)
Так же можно использовать service discovery ПО, которое обеспечит разрешение имен DNS (например consul, но это потребует поднятия отдельного сервиса на ec2\ecs для обслуживания service discovery), или использовать service discovery предлагаемый AWS: Cloud Map - он использует route53 private zone для регистрации сервисов и разрешения имен.
3.
Сертификаты
Для сервисов, которые доступны публично - ничего сложного: используйте Certificate Manager для выпуска сертификатов на ALB или же LetsEncrypt если вы используете собственное ПО для прокси
Для сервисов, находящихся в приватных подсетях и недоступных публично:
- Можно забить и работать без TLS - сеть приватная, защищать или не защищать общение между сервисами в приватной подсети зависит от уровня вашей паранойи.
- ACM Private CA про который вы уже знаете
- В случае использования service discovery ПО можно использовать функционал предлагаемый решениями для service mesh, например consul connect service mesh: ваше приложение общается с прокси консула, а тот, обеспечивая TLS между нодами, направляет трафик приложения на нужный сервис

P.S. совершенно неясно зачем в тегах микротик

Comments

[Alex Rodridez]

Спасибо за развернутый ответ. Строгой необходимости в использовании private DNS нету.
Поэтому не буду заморачиваться и не буду использовать private DNS.
я параноик и поднял бы LetsEncrypt, но вы убедили что нет особого смысла для траффика меж инстансами.

П.С. я писал Route53(ненавижу микротик) - хабр автозаменил видимо на что-то свое))

[Евгений Хлебников]

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

[Alex Rodridez]

сейчас как раз разбиваю на VPC с разными private CIDR и буду поднимать VPC peering и микросервисы будуть общаться через брокер consul - там то весь траффик с TLS идет, так что сертификаты не нужны будут

Answer 2

[Vitaly Karasik]

Или достаточно юзать Elastic IP для каждой машинки

Независимо от DNS, стоит использовать private адреса - быстрее и дешевле (плата за траффик).

Comments

[Alex Rodridez]

Спасибо за фитбек.
т.е. между инстансами внутри инфраструктуры мы используем private static IP. А для вызовов извне можно навесить дополнительный интерфейс с public static IP и использовать Route53.
Как тогда быть с сертификатами? Использовать OpenSSL и обновлять их раз в скажем год?

[Vitaly Karasik]

Как тогда быть с сертификатами?

Или Letsencrypt со скриптом для автоматического обновления, или AWS Certificate manager и внутренние LB.

[Alex Rodridez]

Vitaly Karasik, AWS cert mngr нельзя использовать для private zones.
разве что использовать ACM Private CA
но он стоит 400$ в месяц

[Vitaly Karasik]

Alex Rodridez, вы правы, забыл.
ИМХО, все равно есть workaround - использовать публичную DNS zone с private адресами.
Не пробовал, честно говоря. Плюс надо подумать о +\-. Параноики наверно скажут что некрасиво рассказывать о приватных адресах всему интернету.