Удалённый доступ разработчика к Google Cloud VPC: выберите путь

Разработчику нужна одна SSH-сессия, порт базы данных или широкий доступ к десятку частных сервисов, и каждый из этих запросов выглядит как один и тот же вопрос. Это не так. Назначения, протоколы и задействованные идентичности определяют, какой путь доступа в Google Cloud подходит, а выбор самого широкого по умолчанию создаёт работу, которой вам не нужно было владеть.

Запишите назначения и протоколы

Перечислите частные адреса, порты и протоколы, которые действительно нужны работе, затем отметьте, какие идентичности должны проверяться отдельно. Порт базы данных и частная зона DNS — разные требования, а служба UDP полностью исключает один из вариантов ниже. Письменный список также показывает, что вы не предоставляете. Именно об этой части спрашивают рецензенты.

Сделайте это до открытия прослушивателя. Список позже становится приёмочным тестом, и это единственный надёжный способ отличить узкий туннель от широкого, который просто случайно работает.

IAP для нескольких служб TCP

Проброс TCP в Identity-Aware Proxy даёт аутентифицированный туннель к подходящим ресурсам VM, не выставляя службу в интернет. Обычная форма — gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, а один порт можно пробросить локально с помощью gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Три вещи должны совпасть: вызывающему нужна роль доступа к туннелю IAP, межсетевой экран должен пропускать диапазон источника IAP, а назначение должно быть достижимо на экземпляре. Разрешение на создание туннеля — это не учётные данные базы данных, не вход SSH и не сеанс RDP, поэтому оставьте аутентификацию приложения там, где ей место.

Проброс TCP в IAP — это не VPN третьего уровня. Он переносит TCP к выбранному назначению, а не произвольный трафик IP или UDP, и плохо подходит, когда приложению нужен частный DNS через множество служб.

VPN удалённого доступа для более широкой доступности

Когда требуется несколько назначений, протоколов или частных зон DNS, лучшая форма — явно управляемый VPN удалённого доступа на VM или поддерживаемом устройстве. Это развёртывание отдельно от управляемого Google Cloud VPN: вы владеете регистрацией идентичности клиента, обновлениями программного обеспечения, маршрутами клиента и обратными маршрутами в VPC.

Планируйте весь список, а не только публичный прослушиватель. Включите пул туннелей, маршрут VPC обратно к нему, управление пробросом, разрешение имён DNS и политику доступа для каждой службы. VPN, который подключается, но не может разрешать внутренние имена, проваливает рабочий процесс разработчика так же полно, как и тот, который никогда не подключается.

Cloud VPN — это шлюз сайта, а не профиль ноутбука

Google Cloud VPN соединяет партнёрские шлюзы через IPsec, и его часто задаваемые вопросы отделяют эту роль «сайт-сайт» от доступа «клиент-шлюз». Создание туннеля не создаёт профиль, который сотрудник импортирует на ноутбук. Различие важно, когда кто-то просит профиль Cloud VPN. Ответ — другой продукт.

Шлюз хорошо делает одно: даёт машинам за офисной сетью маршрут в VPC. Он не аутентифицирует каждого сотрудника и не выдаёт разрешения приложения, поэтому эти политики остаются на сетевом и прикладном уровнях, где их можно применять по идентичности.

Проверьте и запишите

Сначала проверьте самое узкое назначение, затем то, которому нужен DNS, а затем назначение, которое должно оставаться запрещённым. Запускайте каждый тест с того же клиента, который будет использовать путь в производстве, потому что успешный тест с рабочей станции администратора мало что доказывает о ноутбуке разработчика с другой сетью.

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