Google Cloud - невозможно получить доступ к частной базе данных Cloud SQL в одной сети VP C из другой сети VP C

Question

Наша установка включает в себя - основной VP C, где у нас есть вычислительные механизмы и Postgres базы данных, созданные с частным IP. Давайте назовем его main-network, - Vault развернут в своем собственном VP C и доступен через Loadbalancer (согласно рекомендациям). Давайте назовем это vault-network.

В main-network экземпляры вычислений могут получить доступ к БД с частным IP-адресом как к БД, где при создании была создана main-network в качестве родительской сети. Рассматривая различные детали VP C, кажется, что процесс создания автоматически создает частный доступ к сервису, как описано в документации. .

Проблема - для базы данных Vault secret-engine , Vault необходимо иметь доступ к БД для динамического генерирования секретов. Я попытался создать пиринг сети VP C между main-network и vault-network и подтвердил (через netcat), что могу успешно обращаться к машинам в main-network с машин в vault-network.

Однако я не могу получить доступ к экземплярам БД с узлов в vault-network.

Можно ли разделить доступ к частной службе с одноранговой сетью vp c?

Я не хочу, чтобы БД публиковались c, если только это не единственный способ .

Answer 1

Поскольку ваше Облако SQL отсутствует в вашем VP C, но между облаком SQL и вашим VP C выполняется пиринг VP C, вы не можете достичь другого VP C сеть пирингом. Как сказал Джон, он назван транзитивностью и описан в VP C ограничениях на пиринг

Только коммуникационные сети могут взаимодействовать. Транзитивный пиринг не поддерживается. Другими словами, если VP C сеть N1 одноранговая с N2 и N3, но N2 и N3 не подключены напрямую, VP C сеть N2 не может обмениваться данными с VP C сетью N3 через VP C Сетевое пиринг.

К сожалению, вы не можете создать пиринг между вашей облачной SQL и сетью VP C (вашей сетью хранилищ) другого проекта, как предложил Джон. Я вижу только 2 решения, чтобы решить эту проблему.

• настроить проход через VM, который только пересылает трафик c. Micro VM достаточно для этого, но вы должны поддерживать его, чтобы позаботиться о высокой доступности, (...)
• Настройка общего VP C с вашими 2 проекты внутри. Настройте свой частный IP-адрес Cloud SQL на общий ресурс VP C su bnet.

Answer 2

Я обратился в службу поддержки Google для нашей учетной записи и спросил их об этой проблеме, и они подтвердили, что невозможно иметь транзитивный VP C пиринг

VP C пиринг не транзитивный, этот сценарий невозможен при использовании пиринга VP C между сетями VP C:

облако SQL <[VP C пиринг]> VP C «основная сеть» <[VP C Peering]> VP C «vault-network».

Создание общего VP C в первую очередь наносит ущерб цели создания отдельной сети, как если бы сделать узлы хранилища напрямую доступными в общем виртуальном VP C.

Парень из Google предложил создать VPN:

В качестве обходного пути вы можете создать VPN между виртуальным VP C сетей «основная сеть» и «сеть хранилища»:

Облако SQL <[VP C Пиринг]> VP C «Основная сеть» <[Cloud VPN]> VP C «хранилище-сеть».

Мне нужно время, чтобы подумать, хотим ли мы go по этому пути или нет.

На данный момент я внес белый список IP-адреса кластера хранилища в конфигурацию settings.ip_configuration.authorized_networks экземпляра базы данных, чтобы предоставить доступ к сети хранилища. Недостатком этого является то, что база данных теперь имеет общедоступный c IP, что не обязательно является плохим, поскольку брандмауэр блокирует доступ к нему c.

Спасибо всем за их предложения.