Привет! Меня зовут Амир Уразалин, я DevOps-инженер в KTS.

В аутсорсинговой модели мы одновременно ведем несколько крупных проектов, каждый со своей инфраструктурой, окружениями и требованиями безопасности. При этом команда инженеров общая, а доступ к виртуальным машинам должен управляться централизованно, прозрачно и безопасно.

По мере роста числа проектов и серверов управлять доступом становилось все сложнее, поэтому мы начали искать новое решение.

Оглавление

• Где начали проявляться ограничения старой схемы

• Что такое Warpgate

• Чем Warpgate отличается от jump-хостов, VPN и Teleport

• Архитектура решения

  • SSO через Keycloak

  • Доступ к инфраструктуре as-a-code

• Что Warpgate не делает

• Что изменилось на практике

Где начали проявляться ограничения старой схемы

Изначально модель была классической: Ansible-плейбук на каждом проекте создавал пользователей и доставлял их публичные SSH-ключи на 100+ виртуальных машин. Это работало, но со временем стали заметны минусы такой схемы:

• Нет связи с корпоративной учетной записью. Доступ к серверам определяется SSH-ключом, а не ролью пользователя или его актуальным статусом в компании.

• Доступ приходится обновлять вручную на каждом проекте. При добавлении нового инженера нужно отдельно прогонять плейбуки на инфраструктуре каждого проекта.

• Отзыв доступа занимает время. Чтобы убрать доступ, нужно прогнать playbook и убедиться, что он применился на всех хостах. Если какая-то машина была недоступна, то доступ может остаться, появляется угроза безопасности.

• Сложно понять, кто подключался к серверу. При инциденте приходится искать информацию в логах на отдельных машинах.

Ansible отлично справляется с конфигурацией серверов, но доступ к инфраструктуре — это не только конфигурация, это политика и контроль. В какой-то момент стало очевидно: мы управляем ключами, но не управляем доступом.

А доступ к инфраструктуре все-таки должен определяться не наличием SSH-ключа на сервере, а ролью пользователя в корпоративной системе и актуальным статусом в компании. Стало понятно, что нужна другая модель доступа.

Доступ должен быть связан с корпоративной учетной записью. Инженер проходит аутентификацию через SSO, а права к серверам определяются его ролями или группами. Если человек меняет роль или уходит из компании, его доступ должен обновляться автоматически.

Важно, чтобы решение работало в продакшене без лицензионных ограничений. Плюс важно было иметь возможность управлять конфигурацией и списком серверов декларативно — чтобы не добавлять 100+ виртуальных машин вручную.

При этом единая точка входа не должна становиться single point of failure. Поэтому хотелось иметь возможность развернуть решение в Kubernetes и запустить несколько реплик для отказоустойчивости.

Разбираем, как мы внедрили клиентам Warpgate bastion с SSO, RBAC и IaC вместо набора jump-host и Ansible-плейбуков.

Что такое Warpgate

Warpgate — это опенсорсный сервис, который работает как прозрачный бастион-хост для доступа к внутренним и публичным ресурсам: SSH, HTTPS, базам данных (MySQL, PostgreSQL) и Kubernetes.

Warpgate принимает подключение пользователя, проверяет его аутентификацию и роли, после чего проксирует соединение напрямую к целевому ресурсу. 

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

Сервис поддерживает SSO и двухфакторную аутентификацию, записывает сессии и позволяет посмотреть историю подключений через встроенный веб-интерфейс. Фактически Warpgate становится единой точкой доступа к инфраструктуре, через которую проходят все подключения.

Чем Warpgate отличается от jump-хостов, VPN и Teleport

Обычно такие решения приходится дополнительно сравнивать и отдельно обосновывать выбор. В случае с Warpgate это оказалось проще: в README проекта на GitHub уже есть сравнительная таблица с отличиями от других подходов.

Источник: официальное сравнение в README проекта Warpgate на GitHub, перевод мой.

Для нас здесь были важны простые вещи: SSO без лишних костылей, отсутствие лицензионных ограничений и возможность управлять доступами и конфигурацией через код. По этому набору требований Warpgate нам подошел лучше всего.

Архитектура решения

Чтобы было проще понять, как все это работало на практике, ниже я набросал упрощенную схему взаимодействия основных компонентов.

SSO через Keycloak

Аутентификацию в Warpgate мы настроили через Keycloak по OIDC. В Keycloak у нас заведены группы, которые соответствуют ролям или проектам. Например, группа /teams/devops/project-A означает, что пользователь должен получить доступ к инфраструктуре проекта project-A.

Дальше схема простая: человека добавляют в нужную группу в Keycloak, после чего он заходит в Warpgate через SSO. Warpgate получает группы пользователя из OIDC-токена, автоматически создает ему аккаунт и назначает роль по настроенному маппингу.

За счет этого доступ к проектам управляется через группы в Keycloak. Чтобы выдать доступ, достаточно добавить человека в нужную группу. Чтобы отозвать — убрать из нее.

Ниже показана часть конфигурации warpgate.yaml:

sso_providers:
  - name: keycloak
    label: "Login with Keycloak"
    auto_create_users: true
    provider:
      type: custom
      client_id: warpgate
      client_secret: $OIDC_CLIENT_SECRET
      issuer_url: $ISSUER_URL
      scopes: ["openid", "email"]
      role_mappings:
        '/teams/devops/warpgate-admin': 'warpgate:admin'
        '/teams/devops/project-A': 'project-A'
        '/teams/devops/project-B': 'project-B'

В этом примере группа /teams/devops/warpgate-admin маппится на админскую роль в Warpgate, а группа /teams/devops/project-A — на роль, которая дает доступ к ресурсам проекта project-A.

Доступ к инфраструктуре as-a-code

У Warpgate есть свой Terraform Provider, и мы активно его используем. Через него мы описываем не просто список серверов, а всю схему доступа: какие есть роли, к каким ресурсам они привязаны и через какой шлюз идет подключение.

Для нас это особенно важно, потому что проектов много. Если управлять ресурсами, ролями и доступами вручную через UI, то при росте числа проектов такая схема просто перестает масштабироваться. Особенно это заметно при подключении нового клиента: если в его инфраструктуре 100+ серверов, заводить их руками в интерфейсе долго, неудобно и просто рискованно — слишком легко ошибиться в адресах, ролях или привязках доступа.

Сама Terraform-структура у нас отражает простую идею. В корне описан центральный Warpgate. Дальше каждый клиентский проект вынесен в отдельную папку, чтобы все его ресурсы, роли и правила доступа лежали отдельно и не смешивались с другими.

Если инфраструктура проекта находится во внутреннем контуре и недоступна напрямую, внутри его папки появляется inner. В нем описан отдельный Warpgate, который играет роль шлюза и дает доступ к внутренним ресурсам клиента.

В итоге структура остается понятной: в корне находится центральная точка входа, а внутри проектов отдельно описан доступ до внутренних ресурсов клиента, например до виртуальных машин с внутренними IP.

Что Warpgate не делает

Важно понимать, что Warpgate не отменяет Ansible полностью. На целевых ВМ все равно нужен технический пользователь, под которым Warpgate будет подключаться к хостам.

Но разница в том, что этот пользователь один, и его не нужно создавать заново для каждого инженера. Вместо раскатки множества пользователей и SSH-ключей на все машины мы поддерживаем один технический доступ со стороны Warpgate, а права инженеров уже управляются централизованно через SSO и роли.

Это заметно проще масштабируется: когда в команде появляется новый инженер, не нужно раскатывать нового пользователя и новый SSH-ключ по всем проектам. Достаточно выдать ему нужную роль в SSO, а остальное уже отработает Warpgate.

Что изменилось на практике

Главный эффект от такого подхода — доступ инженеров к клиентской инфраструктуре больше не управляется через персональные SSH-ключи и локальных пользователей на серверах.

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

В итоге схема доступа становится проще в сопровождении и лучше масштабируется на несколько клиентских проектов.

Если вы тоже используете Warpgate или похожие решения, делитесь опытом в комментариях, будет интересно сравнить подходы!

А если интересно почитать еще о том, как мы работаем с инфраструктурой, рекомендую статьи моих коллег:

• Как мы проводим IT-аудит: живой кейс, инженерный подход и надежность без фанатизма

• MLOps-пазл: как мы собрали единый конвейер для ML-моделей из разрозненных инструментов

• Grafana Operator — дорога к IAC или путь в никуда?

• Единый вход для ML-стека на примере Keycloak

• BuildKit в Kubernetes: мануал по быстрой и автомасштабируемой сборке проектов