Я запускаю PostgreSQL на экземпляре Google Cloud Compute Engine, и в настоящее время PostgreSQL настроен на прием подключений из любой точки мира. Идея заключается в том, что я использую брандмауэр для управления доступом вместо того, чтобы каждый раз входить на сервер.
В настоящее время у меня есть правило брандмауэра под названием development-allow-psql, чтобы убедиться, что ничего не настроено неправильно, я настроил его так, чтобы разрешить доступ отовсюду:
Targets: All instances on network
Source Filter: IP Ranges
Source IP Ranges: 0.0.0.0/0
Second Source Filter: None
Specified protocols and ports: tcp:5432
Бег
psql "dbname=mydb host=__.___.__.__ user=myuser password=mypassword port=5432"
Подключаюсь мгновенно, но из любой точки мира, а не только из тех мест, которым я хочу разрешить доступ.
Эти экземпляры автоматически создаются с помощью Instance Groupшаблона Instance Template
, настроенного на создание экземпляров со следующими параметрами:
Network tags: myapp-api, http-server, https-server
Network: development
Subnetwork: development (with address range 10.154.0.0/20)
Я хочу ограничить доступ к этому экземпляру БД для экземпляров, которые имеют myapp-apiтег as или имеют подсеть 10.154.0.0/20или и то, и другое. Поэтому я меняю настройки брандмауэра следующим образом:
Targets: Specified target tags
Target tags: myapp-api
Source Filter: Subnets
Subnets: 10.154.0.0/20
Second Source Filter: None
Specified protocols and ports: tcp:5432
Это блокирует доступ к psqlкоманде, которую я запустил ранее (команда psql запускается из экземпляров Docker, к которым я получаю доступ через docker exec -ti -u0 my-instance-api-dev-small bash)
Если я сейчас изменю на
Targets: All instances on the network
Source Filter: Subnets
Subnets: 10.154.0.0/20
Second Source Filter: Source tags
Source tags: myapp-api
Specified protocols and ports: tcp:5432
Он все еще блокирует весь доступ. Если я сейчас уберу фильтр второго источника и буду фильтровать только по подсети, доступа все равно не будет.
Targets: All instances on the network
Source Filter: Subnets
Subnets: 10.154.0.0/20
Second Source Filter: None
Specified protocols and ports: tcp:5432
Если я заменю фильтр источника подсети на фильтр тегов:
Targets: All instances on the network
Source Filter: Source tags
Source tags: myapp-api
Second Source Filter: None
Specified protocols and ports: tcp:5432
... доступа по-прежнему нет.
То же самое при выборе исходного фильтра подсетей и простом выборе всех подсетей.
Переключение на:
Targets: All instances on the network
Source Filter: IP ranges
Source IP ranges: 0.0.0.0/0
Second Source Filter: Source tags
Source tags: myapp-api
Specified protocols and ports: tcp:5432
он снова позволяет всем (даже за пределами Google Cloud) подключаться, даже если я указал исходный тег
Изменение диапазона IP-адресов на 10.154.0.0/20 снова блокирует всех
Targets: All instances on the network
Source Filter: IP ranges
Source IP ranges: 10.154.0.0/20
Second Source Filter: Source tags
Source tags: myapp-api
Specified protocols and ports: tcp:5432
Замена диапазона IP-адресов на внешние IP-адреса экземпляров, например, 35.189.124.141/32работает, но поскольку эти IP-адреса являются эфемерными, это не решение, поскольку потребуется обновлять правила брандмауэра каждый раз, когда автоматическое масштабирование добавляет новые экземпляры с новыми IP-адресами.
Как настроить брандмауэр так, чтобы он разрешал только экземпляры из определенной подсети и/или с определенными тегами? То, что я делаю, похоже, не работает.
решение1
При переключении с внешнего IP-адреса экземпляра базы данных на его внутренний IP-адрес внезапно все вышеперечисленные комбинации начинают работать.
psql "dbname=mydb host=internal-ip-address-here user=myuser password=mypassword port=5432"
Оказывается, при использовании тегов брандмауэр смотрит на внутренний IP-адрес вместо внешнего IP-адреса.
Targets: All instances on the network
Source Filter: Subnets
Subnets: 10.154.0.0/20
Second Source Filter: Source tags
Source tags: myapp-api
Specified protocols and ports: tcp:5432