Транспорт

Связь Keeper-а с агентом построена на одном долгоживущем gRPC bidirectional stream поверх mTLS. Этот раздел — про то, как защищён канал и почему агенту не нужны входящие порты.

gRPC bidirectional stream поверх mTLS

Основной канал между Keeper-ом и агентом — двунаправленный gRPC-стрим, обёрнутый во взаимный TLS (mTLS):

Взаимная аутентификация. TLS-рукопожатие проверяет обе стороны: агент убеждается, что говорит со своим Keeper-ом, а Keeper — что на проводе известный ему хост с валидным SoulSeed. Анонимных пиров канал не принимает.
Авторитет идентичности — сам сертификат. Кто именно подключился, определяется по mTLS-сертификату агента (его отпечаток сверяется с реестром), а не по идентификатору, который агент сообщает в полезной нагрузке. Подделать чужую идентичность, прислав чужой SID в сообщении, нельзя — он не является доказательством.
Один активный стрим. В каждый момент агент держит ровно один стрим к одному Keeper-у; переключения между инстансами Keeper-а бесшовны (новый стрим открывается до закрытия старого).

По этому стриму Keeper доставляет задачи, а агент возвращает события и отчёты о прогоне — всё в одном защищённом соединении.

Соединение инициирует агент

Стрим всегда открывает агент — Keeper никогда не подключается к управляемому хосту сам (в pull-режиме). Это даёт ключевое свойство для безопасности периметра:

На управляемых хостах не нужны входящие порты. Агенту не требуется открытый порт, на который кто-то ходит извне; он сам устанавливает исходящее соединение к Keeper-у.
Единственный открытый порт на хосте — локальный listener метрик, и тот по умолчанию слушает loopback и наружу не торчит.

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

Bootstrap-канал

Онбординг нового агента (обмен токена и CSR на SoulSeed) идёт по отдельному listener-у с server-only TLS — на этом шаге у агента ещё нет своего сертификата для взаимной аутентификации. Как только агент получил SoulSeed, дальнейшее общение переходит на основной mTLS-стрим. Детали процедуры — Идентичность → Онбординг через CSR.

Общий PKI-корень

Чтобы mTLS работал, обе стороны должны доверять одному удостоверяющему центру.

Серверный TLS Keeper-а и сертификаты агентов выпускаются из одного PKI-корня (PKI Vault, см. Секреты). Если серверный сертификат Keeper-а подписан другим корнем, агенты ему не поверят — взаимное доверие сломается, и стрим не установится.
Практический вывод при настройке: серверный сертификат Keeper-а нельзя брать «откуда попало» (например, публичный ACME-сертификат для веб-домена) для gRPC-канала к агентам — он должен происходить из того же корня, что и SoulSeed-сертификаты хостов.

Управление этим PKI (выпуск, подпись, ротация) берёт на себя Vault; приватный ключ CA живёт в Vault и на дисках кластера не материализуется.