Віддалений доступ розробника до 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, а далі призначення, яке має залишатися забороненим. Запускайте кожен тест із того самого клієнта, який використовуватиме шлях у виробництві, бо успішний тест із робочої станції адміністратора мало що доводить про ноутбук розробника з іншою мережею.

Запишіть вибрану модель, охоплювані призначення, ідентичності, які вона перевіряє, і поведінку під час збою, коли шлях недоступний. Саме цей запис не дає наступному запиту мовчки розширити тунель замість додавання одного призначення до задокументованого дизайну.