Как DevOps-команда перевела SSH-доступ на Warpgate и перестала править ключи Ansible’ом — VogueTech

Что появилось / что изменилось

Команда KTS ушла от классической схемы «Ansible + SSH-ключи на сотне серверов» к единой точке входа на базе Warpgate. На практике это дало несколько конкретных изменений:

Единая учетная запись вместо зоопарка ключей
Доступ к серверам теперь завязан на корпоративный SSO через Keycloak, а не на то, успели ли положить публичный ключ на нужную виртуалку.
Автоматическое управление жизненным циклом доступа
Роли и группы в корпоративном каталоге определяют, к каким хостам и сервисам может подключаться инженер. Ушел из компании или сменил роль — доступ обновляется централизованно, без ручного прогона playbook’ов по 100+ машинам.
Единая точка входа в SSH, базы и Kubernetes
Warpgate проксирует не только SSH, но и HTTPS, MySQL, PostgreSQL и Kubernetes-кластеры. Подключения идут через один бастион вместо набора jump-хостов и VPN-профилей.
SSO и 2FA «из коробки»
Не нужно прикручивать PAM-плагины и городить отдельную авторизацию на каждом сервере. Warpgate работает с SSO и двухфакторной аутентификацией сразу после интеграции с Keycloak.
Аудит и запись сессий
Сервис логирует подключения, поддерживает запись сессий и аудит команд. При разборе инцидента не нужно собирать крошки логов по всем серверам.
Декларативное управление инфраструктурой доступа
Конфигурацию Warpgate и список целевых хостов можно описывать как код. Добавление нового проекта или сотни виртуалок превращается в изменение конфигов, а не ручное кликанье.
Отказоустойчивость без единой точки поломки
Warpgate разворачивается в Kubernetes, можно запустить несколько реплик и не бояться, что один бастион уронит доступ ко всей инфраструктуре.

Как это работает

Warpgate — это self-hosted бастион-сервис с открытым исходным кодом. Он сидит между инженером и целевым ресурсом и выполняет три основных задачи:

Аутентификация через SSO
Пользователь подключается к Warpgate (по SSH, HTTPS или другому поддерживаемому протоколу). Warpgate перенаправляет его в Keycloak по OIDC. После успешного логина сервис получает набор ролей и групп пользователя.
Авторизация по ролям (RBAC)
В конфигурации Warpgate описаны правила: какие роли могут ходить на какие хосты, по каким протоколам и с какими правами. На этом этапе сервис решает, пропускать соединение дальше или отклонять.
Проксирование и аудит
Если доступ разрешен, Warpgate устанавливает соединение с целевым сервером и прозрачно проксирует трафик. При этом он может:
- записывать сессию целиком;
- логировать команды (для SSH);
- сохранять историю подключений в своей базе.

Ключевой момент: на целевых серверах не нужно ставить агентов. Для внедрения достаточно развернуть Warpgate и прописать в нем список хостов и правил доступа.

Что это значит для вас

Когда Warpgate помогает

Много проектов, одна команда инженеров
Если вы, как KTS, ведете несколько крупных заказчиков, каждый со своей инфраструктурой, Warpgate снимает боль с раздачей и отзывом SSH-ключей, особенно когда счет идет на сотни виртуалок.
Жесткие требования по безопасности и аудиту
Нужны SSO, 2FA, запись сессий и понятная история, кто и когда заходил на прод — Warpgate дает это из коробки, без покупки коммерческой подписки.
Вы уже живете в Kubernetes
Если ваша инфраструктура крутится в Kubernetes, Warpgate органично вписывается: разворачиваете несколько реплик, подключаете Keycloak и описываете конфиг как код.
Нужно централизовать доступ не только к SSH
У вас есть базы данных, Kubernetes-кластеры, внутренние веб-интерфейсы — всё это можно завести за один бастион и управлять доступом через единые правила.

Когда лучше поискать другой вариант

Небольшой стартап или один сервер в облаке
Если у вас один-два сервера и команда из трёх человек, Warpgate может оказаться избыточным. Проще обойтись обычными SSH-ключами и минимумом автоматизации.
Нет корпоративного SSO и планов его внедрять
Сильная сторона Warpgate — связка с SSO и ролями. Если у вас нет Keycloak или другого провайдера идентификации, часть преимуществ теряется.
Нужен полностью управляемый SaaS
Warpgate — self-hosted. Его нужно развернуть, обновлять и мониторить. Если вы хотите «чтобы всё сделали за вас» в виде облачного сервиса, стоит смотреть в сторону коммерческих решений.

С точки зрения доступности: Warpgate — опенсорс и разворачивается у вас. Никаких внешних VPN или геоограничений, кроме тех, что накладывает ваш собственный хостинг.

Место на рынке

Автор кейса сравнивает Warpgate с тремя привычными подходами: SSH jump-хост, VPN и Teleport. В README проекта есть таблица, где расписаны отличия.

По ключевым параметрам картина такая:

Гранулярность доступа
Warpgate и Teleport позволяют привязывать пользователей к конкретным сервисам. Классический jump-хост и VPN чаще дают широкий доступ ко всей сети за точкой входа.
Клиенты и удобство подключения
Warpgate и VPN работают с нативными клиентами (SSH, браузер и т.д.). Для Teleport нужен отдельный клиент. Для jump-хоста требуется дополнительная настройка SSH-клиента.
SSO и 2FA
Warpgate и Teleport поддерживают SSO и двухфакторную аутентификацию «из коробки». Для jump-хоста это обычно решают через PAM-плагины, для VPN всё зависит от провайдера.
Аудит и запись сессий
Warpgate и Teleport умеют вести аудит на уровне команд и записывать сессии. Jump-хост и VPN в базовой конфигурации видят только факт соединения. Безопасная запись на целевых хостах затруднена, если у пользователей есть root-доступ.
Модель распространения
Warpgate — опенсорс и self-hosted, без описанных в кейсе лицензионных ограничений. Teleport в полной функциональности — коммерческий продукт. VPN и jump-хост — это скорее паттерны, а не конкретные продукты, их возможности зависят от выбранной реализации.

Если у вас уже есть сложная инфраструктура с десятками и сотнями серверов, Warpgate может стать логичным шагом от «зоопарка ключей и jump-хостов» к более управляемой системе доступа с SSO и RBAC.