Взаимодействие компонентов

В этом документе описано, как основные компоненты Airlock взаимодействуют при установке, подключении агентов и доступе пользователей к ресурсам.

Роли компонентов

Auth Service — единственный компонент кластера с постоянным хранилищем состояния. Proxy Service и агенты не хранят конфигурацию кластера: они получают учётные данные от Auth Service и поддерживают соединение с ним через Proxy Service.

Общая схема

  flowchart TB
    subgraph users [Пользователи]
        airsh[airsh / airctl]
        browser[Веб-браузер]
    end

    subgraph perimeter [Периметр]
        proxy[Proxy Service :443]
    end

    subgraph cluster [Кластер Airlock]
        auth[Auth Service]
    end

    subgraph private [Частная сеть]
        agent1[Агент SSH]
        agent2[Агент Kubernetes]
        agent3[Агент Database]
        res1[Linux-сервер]
        res2[Kubernetes API]
        res3[PostgreSQL]
    end

    airsh -->|TLS login, SSH, kube, db| proxy
    browser -->|HTTPS Web UI| proxy
    proxy <-->|gRPC API| auth
    agent1 -->|обратный туннель| proxy
    agent2 -->|обратный туннель| proxy
    agent3 -->|обратный туннель| proxy
    agent1 --> res1
    agent2 --> res2
    agent3 --> res3
    proxy -->|трафик через туннель| agent1
    proxy -->|трафик через туннель| agent2
    proxy -->|трафик через туннель| agent3

Пользователи обращаются только к Proxy Service (обычно https://airlock.example.com). Ресурсы и агенты в частной сети не открывают входящие порты в интернет — агенты сами устанавливают исходящие обратные туннели к прокси.

Auth Service

Auth Service выполняет функции центра доверия кластера:

• Хранит пользователей, роли, коннекторы SSO и описания ресурсов.
• Управляет центрами сертификации (CA) для пользователей, узлов и сервисов.
• Выдаёт краткосрочные сертификаты после успешной аутентификации.
• Принимает запросы на присоединение агентов (join-токены) и выдаёт агентам долгосрочные сертификаты.
• Записывает события аудита.

Auth Service не принимает пользовательский трафик к SSH, Kubernetes или базам данных напрямую. Клиенты и агенты обращаются к нему через gRPC API; для пользователей этот путь проходит через Proxy Service.

Proxy Service

Proxy Service — единая точка входа:

• Веб-интерфейс — вход пользователя, список ресурсов, запуск приложений, терминал SSH и RDP в браузере.
• Identity-Aware Proxy (IAP) — выдача пользовательских сертификатов после SSO или локального входа; клиент airsh использует эти сертификаты для последующих подключений.
• Маршрутизация — перенаправление SSH, Kubernetes, HTTPS приложений и трафика баз данных к нужному агенту через обратный туннель.
• TLS-маршрутизация — несколько протоколов через один порт 443.

Proxy Service поддерживает постоянные обратные туннели от агентов. Когда пользователь подключается к ресурсу, прокси выбирает агента, зарегистрированного для этого ресурса, и передаёт трафик по уже установленному туннелю.

Несколько экземпляров Proxy Service

В production можно запустить несколько экземпляров Proxy Service — на разных узлах, в разных зонах доступности или регионах. Это даёт:

• Высокую доступность — при отказе одного прокси пользователи и агенты продолжают работать через оставшиеся экземпляры.
• Снижение нагрузки — входящий трафик распределяется между прокси (балансировщик или DNS).
• Меньшую задержку (latency) — прокси можно разместить ближе к пользователям или к агентам, чтобы сократить сетевой путь.

Типовая схема:

  flowchart TB
    users[Пользователи]
    lb[Балансировщик / DNS]
    p1[Proxy 1]
    p2[Proxy 2]
    p3[Proxy N]
    auth[Auth Service]
    agent[Агент]

    users --> lb
    lb --> p1
    lb --> p2
    lb --> p3
    p1 --> auth
    p2 --> auth
    p3 --> auth
    agent -->|туннель| p1
    agent -->|туннель| p2
    agent -->|туннель| p3

Рекомендации:

• Перед прокси — балансировщик нагрузки или DNS с несколькими A-записями; алгоритм round-robin, без sticky session.
• Агенты при подключении устанавливают обратный туннель к каждому Proxy Service в кластере — см. подключение по join-токену.
• Все экземпляры Proxy Service используют один Auth Service и общие TLS-сертификаты для одного домена (airlock.example.com).
• Auth Service также может работать в нескольких экземплярах для отказоустойчивости; состояние кластера хранится в общем бэкенде.

Размещение прокси в регионах, близких к командам пользователей или к пулам агентов, уменьшает RTT при входе и при проксировании сессий.

Агенты

Агент — процесс airlock с одним или несколькими сервисами (SSH, Kubernetes, Database, Application, Desktop), развёрнутый рядом с защищаемыми ресурсами.

Подключение агента к кластеру

1. Администратор создаёт join-токен: airctl tokens add --type=node (или kube, db, app и т.д.).
2. Агент запускается с токеном и адресом Proxy Service.
3. Агент устанавливает TLS-соединение с Proxy Service и регистрируется в Auth Service.
4. Auth Service выдаёт агенту сертификат; агент открывает обратный туннель к прокси.
5. Агент периодически обновляет сертификат и поддерживает туннель.

Агенту не нужен публичный IP-адрес или открытый порт — достаточно исходящего доступа к Proxy Service на порту 443.

Работа агента при доступе пользователя

1. Пользователь аутентифицируется и получает сертификат с ролями и атрибутами.
2. Пользователь инициирует подключение (например, airsh ssh user@host или airsh db connect).
3. Proxy Service проверяет сертификат пользователя и RBAC на стороне Auth Service.
4. Прокси направляет трафик через туннель к агенту, обслуживающему ресурс.
5. Агент повторно проверяет сертификат и политики, затем устанавливает соединение с целевым ресурсом (SSH, API Kubernetes, PostgreSQL и т.д.).
6. События сессии записываются в журнал аудита Auth Service.

Пользователи

Вход и получение сертификата

Пользователь аутентифицируется одним из способов:

• Локальная учётная запись — логин и пароль (+ OTP или WebAuthn при включённом MFA).
• SSO (OIDC / SAML) — внешний провайдер идентификации.

После успешного входа Auth Service выдаёт краткосрочный сертификат, содержащий имя пользователя и роли. Клиент airsh сохраняет сертификат локально; браузер использует сессию для веб-интерфейса.

airsh login --proxy=airlock.example.com --user=alice

Доступ к ресурсам

На каждом этапе проверяется сертификат Airlock; статические пароли к целевым ресурсам пользователю не передаются.

Администратор

Администратор использует airctl для управления кластером: пользователи, роли, токены, ресурсы. airctl может работать:

• на хосте Auth Service (с локальной конфигурацией);
• с рабочей станции после airsh login (через Proxy Service).

Типичные сценарии

Первоначальное развёртывание

1. Установите Auth Service и Proxy Service на контрольном узле (или в Kubernetes).
2. Настройте DNS и TLS для airlock.example.com.
3. Создайте локальных пользователей и роли через airctl.
4. Установите агентов на серверы, в кластеры Kubernetes и рядом с базами данных.
5. Пользователи выполняют airsh login и подключаются к ресурсам.

Ресурс за межсетевым экраном

Ресурсы и агенты остаются в частной сети без входящего доступа из интернета. Агент инициирует исходящее соединение к Proxy Service; пользователи из интернета подключаются только к прокси, который передаёт трафик по туннелю.

Прямое подключение (без прокси)

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