Как аутентифицировать пользователя AWS на конкретном хосте внутри частного облака

Postgresql сначала выполняет обратный поиск DNS при проверке pg_hba.conf. Поэтому важно, что такое обратный DNS. Это также означает, что это не сработает:

hostssl all             replica         .rds.amazonaws.com    md5

Вы можете сделать:

hostssl all             replica         .us-west-2.compute.amazonaws.com    md5

Но если вы правильно останетесь, это оставит очень открытую конфигурацию, которая позволит любому компьютер, работающий в этом регионе AWS, для подключения с правильным паролем md5.

Это оставляет по существу два разных варианта решения этой проблемы.

Вариант 1 - Частная сеть и VPN

С помощью AWS VPC вы можете настроить частную сеть и группы подсетей для своего экземпляра RDS, где ему будут назначаться IP-адреса в IP-пространство, которое вы можете контролировать. Допустим, у вас есть подсеть 10.10.10.0/24. Это значит, что вы можете опубликовать 10.10.10.0/24 в своем pg_hba.conf. Это потребует какой-то VPN-настройки между VPC и вашим сервером.

В зависимости от типа сетевого оборудования, установленного в подвале, вы можете использовать AWS Site-to-Site VPN . В качестве альтернативы вы можете использовать другие решения полочных решений, такие как OpenVPN или WireGuard .

Вариант 2 - Динамическое обновление pg_hba.conf

Если вы не хотите дополнительной сложности VPN. Вы можете иметь скрипт каждые 5 минут, запрашивать имя хоста my-db.random-string.us-west-2.rds.amazonaws.com, а затем обновлять pg_hba.conf по мере необходимости и отправлять сигнал SIGHUP в postgres. Это не самое симпатичное решение, но должно позволить ему работать полуавтоматически. Если для этого соединения не требуется простои, это вряд ли будет идеальным решением.

Воспроизведение (хех) этой идеи здесь и сейчас, когда я знаю, как на самом деле «отвечать» на вопросы по SO.

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

По существу:

1. Зарегистрируйтесь у провайдера ddns, например, DuckDNS.org.
2. Они дают вам поддомен в одном из своих доменов, например flp.duckdns.org.
3. Вы устанавливаете клиент обновления на сервер.
4. Клиент обновления (в основном демон) проверяет обновления IP-адреса, а затем уведомляет провайдера об изменении IP-адреса.
5. Поставщик обновляет запись A на своих серверах имен, чтобы отразить изменение.

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

Пара потенциальных проблем (помимо задержек распространения):

1. Будет ли сохранен клиент обновления между перезагрузками, миграциями или другими действиями AWS? Это в основном вопрос, который у меня возник, потому что я не знаю, как можно настроить / управлять фактическими экземплярами ec2, используемыми для RDS. Можно ли вообще установить что-то дополнительное на сервер?
2. Могут возникнуть проблемы с обратным поиском DNS, когда IP-адрес разрешается на несколько имен хостов. Это потенциально может быть решено с помощью нескольких сетевых интерфейсов с разными внешними IP-адресами, но мы вернулись к большему количеству изменений инфраструктуры.

Я думаю, что проблему № 1 можно решить с помощью довольно простой лямбда-функции и триггеров событий, если у поставщика динамического DNS есть API.

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