Как установить sh защищенное соединение от GAE (с доступом publi c) к частному кластеру GKE

Question

У меня есть стандартная среда Google App Engine (GAE). Эта среда доступна для публикации c Inte rnet, поэтому пользователи могут устанавливать sh подключения. С другой стороны, у меня есть частный кластер GKE (нет доступа к конечной точке publi c). В этом сценарии приложениям в GAE необходимо установить sh соединение с кластером GKE, но нам нужно держать кластер GKE закрытым, поскольку мы не хотим предоставлять доступ к кластеру GKE для публикации c inte rnet. * 1001. *

Я сказал заказчику, что мы можем реализовать его с помощью внутреннего балансировщика нагрузки или промежуточного прокси-сервера, чтобы приложения в GAE могли безопасно достигать частного кластера GKE.

Однако заказчик не доверяет этим альтернативы.

Какие у меня есть альтернативы, чтобы разрешить безопасное соединение приложений из GAE с частным кластером GKE?

Если таковые имеются, не могли бы вы описать аргументы, которые устанавливают эти соединения ( ДАЙТЕ в GKE) безопасны?

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

Answer 1

Учитывая, что у вас есть:

• Стандартный App Engine экземпляр
• Частный GKE кластер
• Другой проект для всех упомянутые ваши ресурсы

Как заявлено @John Hanley:

Какой механизм приложений - стандартный или гибкий? Для стандартной версии вы можете выбрать Serverless VP C Access cloud.google.com / vpc / docs / configure-serverless-vp c -access . Для Flexible, если вы находитесь в том же VP C, у вас уже есть доступ. В противном случае посмотрите на VP C Peering cloud.google.com / vpc / docs / vp c -peering

John Hanley вчера

Оба ваших ресурса находятся в разных проектах. У них отдельная сеть. Существуют решения для связи между двумя проектами, такие как:

• Shared VP C
• VP C Peering

Shared VP C

Shared VP C позволяет организации подключать ресурсы из нескольких проектов к общей виртуальной частной облачной (VP C) сети , чтобы они могли безопасно и эффективно общаться друг с другом, используя внутренние IP-адреса из этой сети.

- Cloud.google.com: Shared VP C

Вы можете попробовать использовать что-то вроде Cloud.google.com: VP-сервер без сервера C Доступ

VP-сервер без сервера C Доступ позволяет подключаться из стандартной среды App Engine и облачных функций напрямую к вашей сети VP C. Это соединение позволяет вашим приложениям стандартной среды App Engine и облачным функциям получать доступ к ресурсам в вашей сети VP C через внутренние (частные) IP-адреса. Использование внутренних IP-адресов увеличивает задержку связи между вашими сервисами Google Cloud и исключает доступ внутренних ресурсов к публике c inte rnet.

Проблема заключается в том, что доступ к Serverless VP C не поддерживается Shared VP C, который требуется, когда у вас есть разные проекты. Ниже приведен фрагмент из документации:

Бессерверный VP C Доступ поддерживает связь с VP C сетями, подключенными через Cloud VPN и VP C Сетевой пиринг . VP без сервера C Доступ не поддерживает устаревшие сети или Shared VP C сети .

- Cloud.google.com: общий VP C

VP C пиринг

Google Cloud VP C пиринг сети позволяет частное RF C 1918 подключение к двум виртуальным частным облачным сетям (VP C) независимо от того, принадлежат ли они к одному и тому же проекту или к одной организации.

VP C Сеть Пиринговая связь позволяет одноранговым сетям VP C, чтобы рабочие нагрузки в разных сетях VP C могли обмениваться данными в частном пространстве RF C 1918. Traffi c остается в сети Google и не пересекает общедоступную c inte rnet.

Cloud.google.com: VP C пиринг

Проблема с VP C Пиринг состоит в том, что он поддерживает Flexible App Engine и , а не Standard App Engine.

VP C Пиринг сети работает с Compute Engine , GKE и Гибкая среда App Engine .

Cloud.google.com: VP C Пиринг: ключевые свойства

Обходные пути

Обходные пути могут быть следующими:

• Создайте все в одном проекте
• Создайте ваше приложение как Flexible

Дайте мне знать, если у вас есть какие-либо вопросы по этому поводу.